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
和美工结合好很多吧
[解决办法]
可恨的是100个人中只有那么几个懂的,其余的家伙即拿这概念来唬我们新人
你们有没大型的项目实例,发我借鉴下~三层和MVC都有就最好
Email:huansha@126.com
[解决办法]
[解决办法]
学习下
[解决办法]
MVC只是谈论三层中的两层。另外，MVC是40年前还没有什么编程模式时最低级、最简单的一个模式，之后哪一个界面层系统没有最简单模式的影子呢？只不过被10年前j2ee拿出来给自己的几个框架（但是这些框架总的来说很烂）的脸上贴金而才重新火了几年。
[解决办法]
你提出具体的问题，或者在各种具体问题中去问，这样比较有效。
例如打开你的界面控件所触发的事件代码看看，通常它应该只有2、3行代码，直接触发一个数据处理类的某个方法即可。代码多了，就说明乱七八糟地把业务逻辑纠结在界面开发内部过多了。界面的变化，只是触发本地机器内部数据库的变化（这些数据可能是保存在本地内存，也可能是实时地跟后台服务交换数据而来），然后数据的变化会触发界面上不同的控件。比如用属性绑定来说，你可以把一个模型对象、或者对象的属性跟许多控件的属性双向绑定，然后当控件属性改变时就会设置到对象属性，而对象处理了数据改变背后的触发计算（例如传递到服务器，重新获取服务器的新数据，计算其它数据等等），然后相关数据对象的属性改变又会因为绑定而自动更新各种关联控件。
这是很简单的分层概念。最基本地，不要在使用控件设计界面时手写许多低级代码，而仅仅用高级的数据绑定、用声明方式简单地设计。美工或者售后技术人员来快速拼凑出界面，而真正的程序只应该去开发组件、行为绑定设置工具、测试工具等，这样各种不同层次的人的工作分开了，写出来的软件自然也就是分层的风格的了。
[解决办法]
在我看来都不是啥好东西，自欺欺人罢了。哪来的可比之处？
[解决办法]
而真正的程序只应该去开发组件、行为绑定设置 --> 而真正的程序元只应该去开发工具组件、行为绑定设置
基本上这是一种工程方法，方便于改变系统设计、自动测试、确保开发进度。而不是时髦的某个编程语句，更不是把工程里的文件弄一堆目录摆放这么简单。
[解决办法]
由于历史原因，实际上，MVC现在是比23个设计模式更加原始、内涵少而外延广的一个模式，比照着23个模式在你千奇百怪的程序中的应用经验，你可以看到MVC这种概念如何应用。它比“吃维生素治百病”还容易成为广告语。
[解决办法]
支持楼主的观点,
楼主用的比较少的文字清晰的说明了MVC和N层模式的联系与区别
我要补充的是:
1、N层模式:更强调代码按职责进行物理分离,以产生重用效果;
2、MVC:更强调引入逻辑上的层(也就是存在着一些虚拟的层,这些层几乎没有自己的实现代码,更多的是使用其它层的接口)来隔离物理上的铰链依赖和相互干扰,各模块的可替换性大大提高,
3、MVC模式在不同粒度上,都可以使得层级关系扁平化，所以适用场景更广泛，恰恰很多人理解太狭隘了，我们甚至会发现一个项目中有n个MVC组合，基于这一点，我同意SP1234在20楼的描述；
4、正是因为2种模式的出发点不同，正如风语者在9楼所说，我们会发现有些项目中2种模式是共存的；
4、最后,层的名字只是为了帮助记忆,别太在意那个名字，重要的是层的灵魂是不是体现了优秀的设计能力
[解决办法]