三层架构简单理解

三层架构：通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。

 

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

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

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

 

 

三层直接各负其责，完善的三层：修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层。这时候就需要引进实体层。

为什么需要实体？

    实体层不属于任何一层，却贯穿于三层之间，是整个三层各负其责的同时又完美的结合在一起。它为我们在关系

数据库与对象之间架起了 一座桥梁，消除了关系数据和对象之间的差异。

    前期我们可以一个数据表对应一个实体，每个表里的字段对应实体的属性。

    每一层（UI——>BLL ——>DAL）之间的数据传递是靠变量或者实体作为参数来实现的，但对于大量的数据来说，

用变量最为参数有点太复杂了，不容易进行参数匹配。而使用实体作为参数就要方便的多，用到那个属性直接拿来用

就行。

     实体类是完全受控制的对象，具有面向对象的基本特征。而且可以自定义行为，实现“封装”。

三层架构与二层架构的区别：

 

当然不是任何时候都需要使用三层或者分层，当业务逻辑简单，没有真正的数据存储层，就不需要三层结构。

 

三层架构的优点：

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

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

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

4、有利于标准化；

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

6、结构更加的明确

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

缺点：

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

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

3、增加了开发成本。

举个生活中的例子：

   他们各负其职，服务员不用知道厨师如何做菜，不用了解采购员如何采购食材；厨师不用知道服务员接待了哪位

 

客人，不用知道采购员如何采购食材；同样，采购员不用知道服务员接待了哪位客人，不用知道厨师如何做菜。

 

如果那天采购员生病了，我们只需要找个人来替代采购员去采购就行，不会影响厨师和服务员的工作。

 

    以上是对三层的一些简单认识，其实三层也好，五层也好，都是将页面显示、业务逻辑控制、数据访问进行解耦。其实如果只是分UI，BLL、DAL三层的话，只是实现了基本的解耦，但是耦合性还是很高的，尤其是中型及其以上的系统来说，简单的三层并不能满足其需求。所以DAL提取除了DBHelper，BLL中提起出了Facade层，还有各层之间其实都应该加上接口，这样系统的灵活性会大大提高。