我对三层架构的理解

本文导航：（排版还不错吧，嘿嘿）

什么是三层架构

概念

• 三层架构通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
• 提示：
  • 三层架构并不是只能是三层确切的说应该叫N-Tier,即多层架构。
  • 三层架构并不是简单的将代码分成三个层次就叫做三层。
  • 三层构架也并不是将程序部署在三个不同的地方上就叫做三层。
• 

三层介绍及其的职责

• 表示层（UI）:主要负责获得数据以及为用户展现数据。例如应用程序中的form窗体和B/S系统中的Web。
  • U层不得分担Bll层的职责，除了一些简单的判断逻辑外不应该包含任何逻辑。

• 逻辑层（BLL）：重要负责逻辑处理，所有的逻辑应该都集中在这一层，事务处理也应该在逻辑层开启。
  • 逻辑层无可厚非的是整个系统的核心，这一层可以分为很多子层，例如：把BLL层分为 Business Flow 和Busines Function 两层，Business Function负责完成一些小的业务功能，而Busines Flow负责将小的业务逻辑组合成大的业务流。
    
  • 事务处理在BLL层开启。因为B层负责处理的就是业务的逻辑，在这层开启事务是最合理的。
  • 逻辑层的设计的好坏直接影响着系统的可扩展性、可维护性、可复用性。所以在逻辑层是使用设计模式最多的地方。
• 数据访问层（DAL）：主要负责对数据库的直接访问，向上层屏蔽数据库差异。
  • 数据访问层，一般也分为两层，主要是将DAL层中的共有的操作抽象出一个类，例如：SqlDBHelper。

层之间的关系以及规则

• 下面是我画的一张简单的三层的ＵＭＬ包图。
  
• 
  

关系

• 系统各层次及层内部子层次之间都不得跨层调用。
• Entity 在各个层之间传递数据。
• 层之间的调用是单向的，由上而下的，即U调用B层，B层调用D层。

规则

• 层之间以实体类形式传送参数，不要以变量形式传送，以变量形式传送不符合面向对象编程的思想。
• 在U层绑定到列表的数据采用DataSet或者DataTable形式返回，除次之外建议都以实体类或者实体集合的方式返回。因为DataSet有很多缺点。具体参考我的这篇博客(弱类型数据集与强类型数据集 )
• 对于每一个数据库表（Table）都有一个DB Entity class与之对应。
• 对于每一个DB Entity 都有一个DAL与之对应。
• DAL都实现同一个接口，这样做是为了屏蔽数据库差异，采用了抽象工厂模式+反射+配置文件的方式后，即使换了数据库，也只是需要改写配置文件就可以了。
• 除了D层其它层都不应该出现SQL语句。
• 设计应该尽量减少各层数据的传递。

三层架构的优缺点

优点

1. 降低维护成本，方便管理。
   • 采用分层的方式架构系统，使得系统各层的组件可以直接替换，更新，直接替换dll文件就可以完成系统的更新。这样就像给汽车换个轮胎一样，你无需再把汽车送到厂家安装，直接更换就可以了。因为组件之间是相互独立的。
   • 逻辑主要在B层，就使得U层也就是客户端不承担太多的职责，即使更新业务逻辑，也无需修改客户端，不用重新部署。
2. 对于不断变化的系统有着先天的优势。
   • 三层的设计就是按照面向对象的思想设计的，程序的可扩展性很强，针对不断变化需求的系统有很大的优势。如果不分层，只要改变一个小的地方，程序就得重新改写编译。
3. 屏蔽数据库差异。
   • 按照三层架构设计的系统，对于数据库的改变表示毫无压力。三层中的D层一个很重要的职责就是屏蔽数据库差异，抽象工厂模式+反射+配置文件使得更换数据库变的简单。即使数据库变成了设计时没有考虑在内的情况，也就是重新写个DAL和DBHelper，而对于系统本身来说也无需重新编译。
4. 适合大型项目及合作开发。
   • 三层架构使得合作开发成为可能，由于各层相互独立，一个小组只需负责一小块就可以。结构化的编程方法面对大型的项目会感到力不从心，因为结构化设计必定会使程序变的错综复杂。
5. 安全性。
   • 三层架构使得界面，业务逻辑，数据访问相互独立。可以在各层之间加密传输数据。业务逻辑层和数据库访问层可以部署在不同的服务器上，甚至业务逻辑也可以分别部署在不同的服务器上。这样加上服务器的防火墙使得系统更加安全。

缺点

1. 执行速度。
   • 由于层多了，由于各层之间要传输数据肯定比直接访问数据要慢。对于对速度要求苛刻的系统可能不是很适合。
2. 代码量大。
   • 初次使用三层架构可能会感觉代码量明显增加，但是我觉得为了以后维护性方便，多写点代码是很值得的。
   • 三层架构各模块相互独立，使得模块的复用性增强，例如一个公司做过一些类似的项目以后，再面对相同的项目就会花费更少的代价。这就是可复用性带来的优势。

总结

1. 层次的划分并不是死的，没有一种分法能够适应所有的系统。学习三层就要了解它的实质了解分层的目的，与其说三层是一种架构不如说它是一种思想。
2. 三层架构是伟大的前人总结出的一种为了实现程序的可扩展性，可复用性，可读性，可维护性以及方便合作开发等而总结出的一种架构。其实三层架构是面向对象发展的必然结果。为了实现上述的几种特点，分层是必然的。
3. 分层没有定法，但是只要奔着高内聚低耦合的面向对象思想去分，只要能够满足封装、复用、扩展、移置等方面的要求就可以。
4. 学习分层就跟学习设计模式一样，开始的时候总是从模仿开始，也会特别在意各种条条框框。但是这却是一个不得不经历的过程，学习分层不是为了学习分层本身，就像学习设计模式不是学习模式本身一样，重要的是在这个过程中理解面向对象设计的魅力，体会前人思想的沉淀。无论是分层还是设计模式都是巨人，我们要做的就是站在它们的肩膀上然后成为巨人，超越巨人。