三层架构

为什么需要三层？

三层的引入：

三层架构是面向对象编程的必然产物，三层架构的目的就是实现“高内聚”“低耦合”目的，下面就来看一下我们饭店的例子，服务员只管接待客人，厨师只管烹炒客人要的美食，采购员只管按照客人需求采购肉，海鲜，蔬菜，他们各司其职共同协作为客人提供美食。

这样有什么好处？假如服务员离职请假了，直接找其他服务员代替就可以，不会对其他的厨师和采购员造成影响，同样当厨师请假了，直接让其他厨师代替就可以，也不会对服务员和采购员造成影响，各个部分之间分工明确，耦合降低了，使得一个部分的变化不会对另一个造成影响，同时使得更容易复用，服务员走了到别的地方也可以当服务员去，同时修改也容易，一个服务员走了再来一个就可以了，所以完全符合面向对象的封装，继承，多态的特征，符合“高内聚”“低耦合”的思想，利于扩展，维护。我们想一下，如果服务员，厨师，还有采购员他们之间没有明确的分工，他们之间互相有关系，互相依赖，因为一个服务员的离开，还需要找相应的厨师，采购员，这对一个饭店的影响是很大的，同样如果是一个系统，因为一个模块的修改，其他想关联的部分都需要修改，这个系统维护起来就会很麻烦。

什么是三层？

三层就是在表示层和数据访问层之间多了一个中间层“业务逻辑层”，防止了表示层和数据库访问层之间直接的交互。

数据访问层DAL

作用：给业务逻辑层提供数据，只负责数据库的读写删，其他的都不管。

从数据源加载数据（select）

向数据源写入数据（insert）

从数据源删除数据（delete）

 

UI显示层

作用：向用户展示特定业务数据，采集用户的输入信息和操作。绝不可以与数据源打交道，需要业务逻辑层来支持。

设计原则：用户至上，兼顾简洁

 

BLL业务逻辑层

从DAL中获取数据，以供UI显示

从UI中获取用户指令和数据，执行业务逻辑

从UI中获取用户指令和数据，通过DAL写入数据源

同时还需要实体类：

在实体类中定义了三层之间都用到的数据，三层都需要引用实体类，如果将来有所改动，只需要改动实体类，方法间调用接口，完全不需要变动，大大减少了程序修改量，迎合了面向对象中接口不变的思想。

甚至在程序设计时，就把将来可能需要的属性预先放在实体类中，这样以后变动时，连实体类都不用变动。

三层之间的依赖关系：

数据访问层DAL：用于实现与数据库的交互和访问，从数据库获取数据或保存数据到数据库的部分。业务逻辑层BLL：业务逻辑层承上启下，用于对上下交互的数据进行逻辑处理，实现业务目标。表示层UI：主要实现和用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层去处理。业务实体Model：用于封装实体类数据结构，一般用于映射数据库的数据表或视图，用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦，为了更好地发挥分层的作用，更好地进行复用和扩展，增强灵活性。通用类库Common：通用的辅助工具类它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。

在我们以前的开发机房收费系统的过程中，我们把所有的程序都写在了windouw窗体中，包括对数据库的访问，还有一些逻辑操作，如果我们想更改数据库，需要改动很多的代码，各部分之间相互关联，一个地方的改变就会导致其他很多地方都需要改动，同时不利于功能的复用，当团队开发的时候，由于各部分之间相互关联，不能够嗯好地分工协作，但是在分层面向对象的开发过程中，各个部分之间的耦合减弱，分工明确，可以很好地实现代码的复用和维护。

三层优缺点

优点：

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

一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如UI人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。

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

松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。

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

4、有利于标准化；

进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。

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

 

三层缺点:

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

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

 

总结：

三层是面向对象开发的产物也是需要，很好地体现了面向对象的封装，继承，多态的特征，“高内聚”“低耦合”的思想，很好地帮助了系统的扩展和维护。