三层架构到底是个什么玩意？

名词解释：

架构：架构一般是针对整个系统的，并非针对某个单独的问题(单独的问题可以用模式来解决)，针对整个系统的”一个蓝图”，对系统的抽象。

模式：软件开发中遇到的一些特定问题，前任总结出来特定的经验、解决方法。

框架：架构设计、模式应用的经验积累的具体代码实现，方便以后的复用。

三层：

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

业务逻辑层BLL(Business Logic Layer)：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。(备注：又称领域层，常用业务规则、数据访问、合法性校验等等) 。其实，逻辑层就像房屋中介，租房买房跟快捷了，但消耗的钱也跟多了。

数据访问层DAL(Data Access Layer)：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。(领域对象：crud)

优点：

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

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

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

4、有利于标准化；

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

6、结构更加的明确；

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

缺点：

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

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

3、一定程度上增加了开发的成本。；

规则

三层结构的程序不是说把项目分成DAL，BLL，WebUI三个模块就叫三层了。下面这几个问题：

1、UILayer里面只有少量(或者没有)SQL语句或者存储过程调用，并且这些语句保证不会修改数据？

2、如果把UILayer拿掉，你的项目还能在Interface/API的层次上提供所有功能吗？

3、你的DAL可以移植到其他类似环境的项目吗？

4、三个模块，可以分别运行与不同的服务器吗？

如果不是所有答案都为YES，那么你的项目还不能算是严格意义上的三层程序。三层程序有一些需要约定遵守的规则：

1、最关键的，UI层只能作为一个外壳，不能包含任何BizLogic的处理过程

2、设计时应该从BLL出发，而不是UI出发。BLL层在API上应该实现所有BizLogic，以面向对象的方式

3、不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在一定的抽象程度上做到系统无关

4、不管是用COM+( Enterprise Server )，还是Remoting，还是WebService之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在涉及的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡做集群。

所以考虑一个项目是不是应该应用三层/多层设计时，先得考虑下是不是真的需要？实际上大部分程序就开个WebApplication就足够了，完全没必要做的这么复杂。而多层架构，是用于解决真正复杂的项目需求的。

三层与MVC的区别

同样是架构级别的，它们有什么相同点和不同点呢？这篇文章讨论一下它们的异同点。希望能帮助读者理解其中的玄机。

其实它们相同的地方在于他们都有一个表现层。

但是他们不同的地方在于其他的两个层。

首先先解释一下MVC。V即View.是视图的意思。C即Controler.是控制器的意思。而M即Model，是模型的意思。这三个里.最不容易理解的应该是Model.就是什么是Model，而为什么叫Model。我先不说为什么叫Model，先解释Controler。

Controller是控制器的意思，所谓控制器，就是将用户请求转发给模型层，经过处理后把结果返回到界面展现的一个中间层，那么Controler到底管什么工作呢？先不说.先来看下在Java Web中这三个层一般的定义，一般在Java Web里，JSP充当V，Servlet充当C,JavaBean充当M，这里的Servlet管什么工作呢？接受输入，转到Model层去处理，处理结果保存后转发到JSP，然后展现数据。所以它的功能就是控制器的基本功能，它就管转发，在V和M之间转来转去。

再来说说M，即Model，在Java Web里说的是JavaBean，我认识的很多人都把JavaBean误认为是实体类，其实JavaBean有比实体类更丰富的定义，在JavaBean中除了其属性和字段，还可以有行为及其事件，JavaBean可以理解为普通Java对象。Java普通对象，就是符合Java规范的所有对象，这和实体类完全是两回事。所以，我认为在MVC中。业务逻辑和数据访问应该放在Model层，也就是V负责展示数据，Controler除了转发不做业务逻辑。真正的逻辑事务，数据访问，甚至算法都放到Model去。

再说三层架构。三层其实很好理解，界面，业务，数据访问，就这三个，从字面都可以理解出它们的意思。我要说的是它和MVC的区别。在三层架构中没有定义Controler的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。

当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是已实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。不一样的概念。虽然名字一样。