三层架构-------理论篇

概念：

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

     各层概念

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

2、业务逻辑层（BLL）：针对详细问题的操作，也能够说是对数据层的操作，对数据业务逻辑处理。

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

 

       注：应用三层离不开还有一个重要的类：实体类，如今接触的主要是数据库表抽象出的类，表中的每一个字段就是一个详细实例。相同跟业务实体相关的事物都能够成为实体类。

     各层的作用

1、数据訪问层：从数据源载入数据（Select）。向数据源写入数据（Insert/Update）;从数据源删除数据（Delete）.                              是对数据的操作。而不是数据库。详细为业务逻辑层或表示层提供数据服务，不包括不论什么与业务相                               关的逻辑处理。

2、业务逻辑层：  从DAL中获取数据，以供UI显示用；从UI获取用户指令和数据，运行业务逻辑。从UI中获取用户指                               令和数据，通过DAL写入数据源。

对数据层的操作。对数据业务逻辑处理。

                              职责机制：UI->BLL->UI；UI->BLL->DAL->BLL->UI

3、表示层：从向用户展现特定业务数据；採集用户的输入信息和操作。

主要表示WEB方式和WINFROM方式。

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

 4、实体类：对于表示层来说，界面通过实体类传递数据。将解析实体对象中封装的数据展示给用户；将用户请求的                       数据封装到实体对象中。

对于业务逻辑层来说，将接受到的实体对象传递到下一层；依据用户请求对实                        体中数据进行处理。

对于数据訪问层来说，从数据库取得数据通过实体类返回。

三层关系图

                                          

   添加实体后的关系图

                                   

优缺点

     长处

            开发者仅仅关注整个结构中的当中某一层；

  能够非常easy的用心的实现来替换原有层次的实现；

           能够减少层与层之间的依赖；

   有利于标准化；

           利于个曾逻辑的复用；

           结构更加的明白。

           在后期维护的时候。极大地减少了维护成本和维护时间；

       缺点

             

           减少了系统的性能。假设不採用分层式结构，非常多业务能够直接造訪获取对应的数据，，如今必须通过中间层来完毕。

             有时会导致级联的改动。这样的改动尤其体如今自上而下的方向。假设表示层须要添加一个功能。为保证其设计符合分层结构，可能须要在对应的业务逻辑层和数据訪问层中都添加对应的代码。

             添加了开发成本。

    下篇是三层结构的实践篇