三层架构

软件架构

描述的对象时直接构成系统的抽象组件。各个组件之间的连接描述了组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象中，组件之间的连接通常用接口来实现。一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

三层架构

        所谓三层，就是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，而是指逻辑上的三层。即使这三个层放置到一台机器上。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。

分层

三层将整个业务英勇划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

                                                                           

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

作用：用于显示数据和接受用户输入的数据。为用户提供一种交互式操作的界面。

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

作用：它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。层与层之间的依赖是向下的。底层对于上层而言是无知的。改变上层的设计对于其调用的底层而言，没有任何影响。如果在分层的设计时，遵循了面向接口设计的思想，那么在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。

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

作用：有时候也称持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。

优点

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

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

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

4.有利于标准化

5.有利于各层逻辑的复用

缺点

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

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

规则

1.UI层：

UI层里边只有少量的SQL语句或者存储过程调用，并且这些语句保证不会修改数据。最关键的UI层只能作为一个外壳，不能包含任何逻辑处理过程。

2.如果把UI层拿掉，项目还能在接口/API的层次上提供所有功能。

3.DAL可以移植到其他类似环境的项目。不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在一定的抽象程度上做到系统无关。

4.三个模块，可以分别运行于不同的服务器上。

5.设计时应该从BLL层出发，而不是UI层。BLL层在API上应该实现所有的逻辑。