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和三层架构是共存的

------解决方案--------------------
MVC
和美工结合好很多吧
------解决方案--------------------
可恨的是100个人中只有那么几个懂的,其余的家伙即拿这概念来唬我们新人

你们有没大型的项目实例,发我借鉴下~三层和MVC都有就最好

Email:huansha@126.com
------解决方案--------------------

探讨

可恨的是100个人中只有那么几个懂的,其余的家伙即拿这概念来唬我们新人

你们有没大型的项目实例,发我借鉴下~三层和MVC都有就最好

Email:huansha@126.com

------解决方案--------------------
学习下
------解决方案--------------------
MVC只是谈论三层中的两层。另外，MVC是40年前还没有什么编程模式时最低级、最简单的一个模式，之后哪一个界面层系统没有最简单模式的影子呢？只不过被10年前j2ee拿出来给自己的几个框架（但是这些框架总的来说很烂）的脸上贴金而才重新火了几年。


------解决方案--------------------
你提出具体的问题，或者在各种具体问题中去问，这样比较有效。

例如打开你的界面控件所触发的事件代码看看，通常它应该只有2、3行代码，直接触发一个数据处理类的某个方法即可。代码多了，就说明乱七八糟地把业务逻辑纠结在界面开发内部过多了。界面的变化，只是触发本地机器内部数据库的变化（这些数据可能是保存在本地内存，也可能是实时地跟后台服务交换数据而来），然后数据的变化会触发界面上不同的控件。比如用属性绑定来说，你可以把一个模型对象、或者对象的属性跟许多控件的属性双向绑定，然后当控件属性改变时就会设置到对象属性，而对象处理了数据改变背后的触发计算（例如传递到服务器，重新获取服务器的新数据，计算其它数据等等），然后相关数据对象的属性改变又会因为绑定而自动更新各种关联控件。

这是很简单的分层概念。最基本地，不要在使用控件设计界面时手写许多低级代码，而仅仅用高级的数据绑定、用声明方式简单地设计。美工或者售后技术人员来快速拼凑出界面，而真正的程序只应该去开发组件、行为绑定设置工具、测试工具等，这样各种不同层次的人的工作分开了，写出来的软件自然也就是分层的风格的了。