从三层架构到MVC

 

这几天学习三层架构和MVC，因为刚刚接触，前几天感到非常的困惑，从网上找了N多资料，看了N多人的看法，也浏览了几本书和视频，这几天稍微有了一点头绪。但是每个人都有自己的看法，甚至有的人的看法在有些人看来都是错误的（我也觉得有的人的看法是错误的），下面谈谈我对他们的理解，希望大家可以指正。

 

        首先说三层架构，即：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。每一层都有自己的职责，完成不同的任务，尽量减少不同层之间的交流，所有内聚性得到了大大的降低。下面是我对百度百科中的图加工之后的，很形象的表达了三层之间的关系。它就像一个夹心饼干，最上层的饼干是一个外表，最下层的饼干起到了不可或缺的支撑作用，中间的奶油将上下层连接起来，完成它们的交互作用。

 

                                   

 

 

        那么三层的到底都是做什么的呢？

1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。

 

       三层是将简单的问题复杂化，使用三层做过项目的朋友都知道用三层架构的项目比不用三层的代码量更加庞大，那还为什么还要分层呢？

         那就说说三层的优点： 
1.解耦。上一层只依赖于下一层，如果测试下一层没有问题，那么问题就只可能出现在本层了。便于发现和改正BUG。 
2.简化复杂问题。就比如tcpip协议的四层模型或OSI七层模型，各层分工明确，将一个复杂问题简化了。
3.便于系统维护/升级。各层间通过接口解耦，接口与实现分离，从而可以非常方便的替换掉实现，或者升级实现等。 
4.逻辑复用。例如原来基于B/S开发的程序现在要改成C/S，那么只要业务层的接口没有改变，那么业务层和数据层都可以直接复用。在如，只要数据访问层接口不变，那么使用便可以有对不同数据库的实现。 
5.便于团队开发。只要各层接口在开发前规定好，那么各层可以独立开发，进化或维护。 
6.方便部署。将各层开发成组件，则可以独立部署。

 

        其实分层也不一定只是分三层，如果你愿意的话你可以分得更多，分层分得少得话就和不分一样了，分得多的话软件的复杂性相应的也会增加，对别人来说也就不好理解了，同样也就不容易维护了。容易维护的产品必定是容易理解的，维护只是一个附带的产物罢了。

 

 

        多分层说了这么多了，下面说说MVC吧。其实MVC和三层不是一种东西，很多朋友都将二者混在了一起，没有真正的弄清二者之间的区别，它们确实也非常的相似，但是不是一种东西，就像让你比较*制度和欧洲联盟一样。

 

         MVC是"Model-View-Controller"的缩写，中文翻译为"模型-视图-控制器"。View就是界面视图，所以我们容易和三层架构相混淆。三层架构为了各司其责，每个人都只顾自己的那点事，不关心别人是怎样实现的，而它们之间相互联系的部分谁都不愿意干，所以在它们中间（UI层和BLL层之间）就应用到了MVC，就像下面老赵（微软高级讲师，赵劼）的这张图所表达的含义一样。

                       

 

        以上都是仅代表我个人的看法，非常诚恳的希望大家提出不同的看法和意见

摘自：许德鹏的专栏