MVC和三层架构的区别，我谈下自己的理解
发表下不成熟的看法，
网上转载量非常高的一篇博客，在说三层架构和MVC的时候，
有一句话是这样说的，“中国社会制度与美国人生活方式有什么区别”
好多人说这个比喻好，个人感觉这个比喻很不太恰当
首先说三层架构：
UI(.aspx)---------> BLL(业务处理)------> DAL(数据处理)----> 永久存储（数据库）
MVC：
MVC(Model View Controller)模型－视图－控制器
很明显都是从整体上“策划”一个web项目的实现逻辑
共同点：三层架构的UI层相当于MVC中的View层，作为视图，再说白一点，都是页面
区别：BLL+DAL相当于MVC中的Model层， Model层实现系统中的业务逻辑，当然也包含了数据访问的逻辑
三层”中典型的Model层是已实体类构成的，而MVC里，Model则是由业务逻辑与访问数据组成的，
Model层又分为不同的层（个人认为就是三层架构的DAL+BLL），它的分层也是为了结构清晰和低耦合，
区别比较大的就是三层架构中没有Control层，而是由单个页面上的控件的事件处理页面与业务逻辑之间
，而MVC中control层是作为联系视图层和Model的纽带，使得整个项目的结构更加清晰，降低了耦合性。
举例说明这两种方法不同的实现思路：A在上海的浦东区逛街，有人要抢劫他，打110报警了，B在闵行区也被劫持，他也打110报警了，他们打110的时候，接电话的是上海市公安局总部指挥中心，对于A，来解救他是浦东分局的警察，对于B，解救他的是闵行分局的警察，对于AB来说，他们不需要关心到底是谁来解救他的，他们只管打110报警（类似于页面数据由action提交到控制器），由110指挥中心确定他的位置然后派出具体的地方警局去营救（控制器根据需求调用model层去完成对应的数据处理）。而三层架构在这个过程中就像A或B被劫持了，他们直接找到当地警（调用BLL层方法）的警察来处理，
不想拿出一堆大概念吓人，本来就不太难理解的东西，别搞的很神奇，
也不是说哪个好那个不好，都是解决问题的不同实现思路，三层架构和MVC并
没有传说中的那样没有任何关系，至于.net的MVC还没有研究过。
这些东西都是源于接手的破项目，不太规范的架构和编码看的我很难受，不管MVC还是三层架构，
只要严格遵循起来，系统的扩展性和课维护性都不会很差。
其抱怨人家留下来的系统烂，其实自己的也好不到那去，只不过是自己写的自己思路上清楚点而已。所以感觉以后要严格要求自己，争取写出的代码清晰一点，规范一点。
[解决办法]
路过...顶一个```
[解决办法]
学习了
[解决办法]
研究研究
[解决办法]
只用过三层，没用过mvc。。。。
[解决办法]
学习了
[解决办法]
没用过MVC，没做过真三层，只做过伪三层
[解决办法]
其实我也不懂，只是感觉也就那么回事！
ps：不喜欢玩概念。
[解决办法]
mvc和三层架构是共存的
[解决办法]
[解决办法]
在我看来都不是啥好东西，自欺欺人罢了。哪来的可比之处？
[解决办法]
而真正的程序只应该去开发组件、行为绑定设置 --> 而真正的程序元只应该去开发工具组件、行为绑定设置
基本上这是一种工程方法，方便于改变系统设计、自动测试、确保开发进度。而不是时髦的某个编程语句，更不是把工程里的文件弄一堆目录摆放这么简单。
[解决办法]
由于历史原因，实际上，MVC现在是比23个设计模式更加原始、内涵少而外延广的一个模式，比照着23个模式在你千奇百怪的程序中的应用经验，你可以看到MVC这种概念如何应用。它比“吃维生素治百病”还容易成为广告语。
[解决办法]
支持楼主的观点,
楼主用的比较少的文字清晰的说明了MVC和N层模式的联系与区别
我要补充的是:
1、N层模式:更强调代码按职责进行物理分离,以产生重用效果;
2、MVC:更强调引入逻辑上的层(也就是存在着一些虚拟的层,这些层几乎没有自己的实现代码,更多的是使用其它层的接口)来隔离物理上的铰链依赖和相互干扰,各模块的可替换性大大提高,
3、MVC模式在不同粒度上,都可以使得层级关系扁平化，所以适用场景更广泛，恰恰很多人理解太狭隘了，我们甚至会发现一个项目中有n个MVC组合，基于这一点，我同意SP1234在20楼的描述；
4、正是因为2种模式的出发点不同，正如风语者在9楼所说，我们会发现有些项目中2种模式是共存的；
4、最后,层的名字只是为了帮助记忆,别太在意那个名字，重要的是层的灵魂是不是体现了优秀的设计能力
[解决办法]
