三层架构

1、什么是三层架构？

　　三层分别为数据访问层(DAL)、业务逻辑层(BLL)、表示层(UI)。在三层架构中将用户接口，商业逻辑，数据保存以及数据访问设计为三个独立的模块，使得每个层可以被单独开发，单独测试，而不影响其它层。也就是说，分层的核心目的是满足开发过程中的“高内聚、低耦合”原则。

　　值得注意的是，这里的三层是指逻辑上的三层，也不仅仅有B/S应用才是三层体系结构。下面是三层的结构示意图：

2、三层中每层的作用？

　　表示层（UI）：

　　　　通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。其作用是为用户提供信息，根据用户的指令调用业务逻辑层中的方法，同时将用户数据作为参数传递给业务逻辑层。

　　业务逻辑层（BLL）：

　　　　对表示层传入的指令及数据做处理，如果本层能够处理就在本层完成，如果需要对数据源进行操作，就调用数据访问层。本层主要处理具体业务、对数据层的操作，本层中保存着调用数据访问层的方法，还担当着将逻辑处理后的数据结果返回给UI层。业务逻辑层无疑是系统架构中体现核心价值的部分。

　　数据访问层（DAL）：

　　　　该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。业务逻辑层中保存着调用数据访问层的方法，而数据访问层保存着对数据操作方法的具体实现。对数据库操作方法的具体实现理应都属于数据访问层。

对于数据访问层和业务逻辑层的关系，如果说数据层是积木，那逻辑层就是对这些积木的搭建。

3、三层之间的调用关系？

　　由上面可以得出，层与层之间是一种弱耦合结构，层与层之间的依赖是单向（向下）的，只能向下调用并且为依次调用，而不能反过来调用和跨层调用。底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。在分层设计时遵循面向接口设计的思想，本层只提供对下层操作的接口。

　　业务逻辑层的设计对于一个支持可扩展的架构尤为关键，三层体系将业务规则、数据访问、合法性校验等工作都放到了中间层进行处理，它又处于数据访问层与表示层中间，起到数据交换中承上启下的作用。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是关键。

4、什么是实体类？

　　除了表示层、业务逻辑层和数据访问层之外，在三层架构中还有一个Modal项，Modal项目中存放的是实体类，被表示层、业务逻辑层、和数据访问层三层依赖（表示在开发结构中就是三层都引用实体类），而实体类并不引用其他三层。那么，实体类是什么？

　　如今大多数的数据库都是关系型数据库，而我们用的编程语言是面向对象思想的，这样就造成了不匹配。解决这一问题的方法就是引入对象关系映射。

　　对象关系映射（Object Relational Mapping）：简称ORM。是为了解决面向对象的类，与关系数据库的表之间，存在的不匹配的现象，通过使用描述对象和关系之间映射的元数据，在程序中的类对象，与关系数据库的表之间建立持久的关系，用于在程序中描述数据库表。本质上就是将数据从一种形式转换到另外一种形式。

　　简单一下讲，对象关系映射是将关系型数据库中的每一张表都做成一个面向对象中的类，表的每个字段都抽取为类的字段（注意类型匹配，如int、string等），并封装成类的属性，设计好构造函数用于类的默认初始化。这样，就完成了关系型数据库中的表到面向对象的类的转换，这样就能方便的通过类来操作数据表了。这种从数据表中抽取出来的类就叫做实体类。这个抽取过程称为对象关系映射（ORM）。

　　实体类与三层的关系示意图：

5、划分三层架构的优缺点？

　　优点：

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

　　　　(2)因为较低的耦合性，可以很容易的用新的实现来替换原有层次的实现； 　　

　　　　(3)可以降低层与层之间的依赖，解耦合； 　　

　　　　(4)有利于标准化； 　　

　　　　(5)利于各层逻辑的复用。 

　　缺点：

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

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

　　小结：在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。人们期待分层设计能够达到“高内聚、低耦合”的设计目标。各层各司其职，使得开发人员分工明确，极大的提高了开发效率。虽然三层架构仍有不可避免的缺陷，但分层确实使代码维护、扩展非常方便，各层一定程度上达到了相互独立的目的，利大于弊。