三层架构知识梳理

   最近学习了一下三层架构的知识，在网上搜集了一些资料，梳理了一下，以后备用，也希望能帮到其他热爱编程的人！

分层的由来：

   在学习网络的时候，书上有这么一句话：任何新技术的出现都必须具备两个条件：一是强烈的社会需求，二是前期技术的成熟！三层架构的出现，想必也顺应了这句话。

   1996年SUN公司推出了java,广受业界的喜爱，其重要的一个原因就是java专门为企业开发提供了多层分布式企业应用模型.在企业中,公司有明确的分工和部门,这些部门很可能不在同一个地区.每一个部门用到的系统一般是不同的.但是我们又希望每一个部门的信息统一起来管理,便于管理层管理.同时,企业的数据对安全性要求一般是很高的.不希望系统每一个部分都部署在每一个员工的PC上.这样显然不是安全的.所以,我们解决的办法就是把系统拆分开来,在J2EE中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。这样,系统的安全性,可靠性大大的提高,充分发挥了分层的作用.自此，分层思想就推广开来。

   现在要谈的三层体系结构，是在客户端与数据库两层之间加入了一个“中间层”，也叫组件层，三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。这三层分别被称为：表示层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。下面具体阐述一下这三层：

 

基本的概念：

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

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

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

各层作用：

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

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

   表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx,如果逻辑层相当的强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。

 

引用关系：

   UI直接引用业务逻辑层（BLL）

   业务逻辑层（BLL）需要引用数据访问层（DAL）

   数据访问层（DAL）所在程序集不引用业务逻辑层（BLL）和表示层（UI）

 

说了这么多的理论，有些抽象，下面用一个形象生动的例子阐述一下：

   结合上图，把一个系统的运行，看作是一个饭点的运营，饭店将整个业务分解为三部分来完成，每一部分各负其责，服务员只管接待顾客、向厨师传递顾客的需求；厨师只管烹炒不同口味、不同特色的美食；后勤工作人员只管提供美食原料；他们三者分工合作共同为顾客提供满意的服务。在饭店为顾客提供服务期间，服务员、厨师、后勤工作人员，三者中任何一者的人员发生变化时都不会影响其他俩者的正常工作，只对变化者进行重新调整即可正常营业。

   我们用三层结构开发的软件系统于此类似，表示层只提供软件系统与用户交互的接口；业务逻辑层是表示层和数据访问层之间的桥梁，负责数据处理和传递；数据访问层只负责数据的存取工作。

三层特点：

优点：
   1.解耦。上一层只依赖于下一层，如果测试下一层没有问题，那么问题就只可能出现在本层了。便于发现和改正BUG。
   2.简化复杂问题。就比如tcp/ip协议的四层模型或OSI七层模型，各层分工明确，将一个复杂问题简化了。

   3.便于系统维护/升级。各层间通过接口解耦，接口与实现分离，从而可以非常方便的替换掉实现，或者升级实现等。
   4.逻辑复用。例如原来基于B/S开发的程序现在要改成C/S，那么只要业务层的接口没有改变，那么业务层和数据层都可以直接复用。在如，只要数据访问层接口不变，那么使用便可以有对不同数据库的实现。

   5.便于团队开发。只要各层接口在开发前规定好，那么各层可以独立开发，进化或维护。
   6.方便部署。将各层开发成组件，则可以独立部署。

缺点：
   分层过多限制了客户对系统的理解能力。Tcp/ip便将OSI七层简化为了4层。另外分层过多也增加了系统的理解难度，当然也看客户的接受能力。虽然增大了灵活性，但同时也限制了客户的理解和同客户的交流。

我们什么时候用三层呐？

   如果一个程序，业务逻辑简单，没有真正的数据存储层，就没有必要抽象出一个业务逻辑层，当具有相当多的业务逻辑，业务复杂到一定程度，而且拥有数据存储介质。我们就考虑使用三层架构了。