三层架构与mvc分层

三层

        三层架构(3-tierapplication)通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的是为了“高内聚，低耦合”的思想。

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

         作用：表示层是系统为用户准备的接口，用户通过表现层来使用系统。将表现层与业务逻辑层、数据访问层的耦合度降低，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。

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

         作用：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。

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

         作用：主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务．

三层架构的实现：

        表现层：UI层只能作为一个外壳，不能包含任何的逻辑处理过程。

        业务逻辑层：是系统架构中体现核心价值的部分，主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。

         数据访问层：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等具体为业务逻辑层或表示层提供数据服务。

优点

1、开发人员可以只关注整个结构中的其中某一层；

2、可以很容易的用新的实现来替换原有层次的实现；

3、可以降低层与层之间的依赖；

4、有利于标准化；

5、利于各层逻辑的复用。

6、结构更加的明确

7、在后期维护的时候，极大地降低了维护成本和维护时间

缺点

1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

3、增加了开发成本。

MVC分层

MVC全名是ModelView Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用于组织代码用一种业务逻辑和数据显示分离的方法，这个方法的假设前提是如果业务逻辑被聚集到一个部件里面，而且界面和用户围绕数据的交互能被改进和个性化定制而不需要重新编写业务逻辑MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

视图

视图是用户看到并与之交互的界面。MVC好处是它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。　

模型

模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用像EJBs和ColdFusionComponents这样的构件对象来处理数据库，被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器

控制器接受用户的输入并调用模型和视图去完成用户的需求，所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

 

三层与MVC的区别：

同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。

在三层架构中没有定义Controller的概念。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了，在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。

也就是说三层中的UI对应MVC中的视图层（view），业务逻辑层（BLL）和数据层(DAL)对应MVC中的(Model),与三层相比Mvc多了一个控制层，mvc控制层实现了视图（表现层）与业务逻辑层的分离降低了视图层与业务逻辑层的耦合度。