典型的三层结构

典型的三层结构分为表示（presentation）层, 领域（domain）层, 以及基础架构（infrastructure）层，而微软的DNA架构定义了三个层：表示层（presentation），业务层（business），和数据存储层（data access），当然J2ee 也有它不同的分法不过都大同小异吧。既然我用.net做的开发，这大三层我无需多说了,根据我的理解，我对此做了更详细的分层,界面外观层、界面规则层、业务接口层、业务逻辑层、实体层、数据访问层、数据存储层共七层，其具体的调用如图1所示

       

（图1）

由图1可以看出，虽然我将系统的架构分为七层，实际上大的方面来说，它就是一个典型的三层架构设计思想。单从这个图来看，数据的调用显得繁琐而抽象，也许这时候就会有人说，我只是想实现界面上与用户交互，然后根据用户的请求将数据读出/写入数据库就好了，为什么要做如此复杂的分层调用呢？从这个问句中我们也只看到了界面和数据库，也就是说从用户的需求来说，就是这两层而已，但是这里我们首先要搞清楚的是三层架构它主要是为程序员为了实现部署、开发、维护企业级数据库系统而服务的。如果我们在中间层实现了对表示层和数据库层的完全脱离，其部署、开发、维护系统的费用和时间至少降低到原来的一半，甚至更多。

系统通过浏览器或应用程序客户端提供与用户的交互平台，并向服务器提交请求（界面外观层）；用户提交请求后，界面规则层对用户的数据按照业务逻辑层要求的接口参数封装规则封装用户数据，然后调用业务接口层对外提供的相应命令接口（界面规则层），业务接口层通过对数据进行解析并分别送入不同的逻辑处理并向用户返回处理结果(业务接口层)；对于数据和命令的不同，处理方式也不同，我们将不同的处理方式都归类，并将接口层传入的数据及命令流入对应处理流程（业务规则层）；这时，不同的处理流程分析数据和命令产生出对应的一个实体，这个实体根据其本身的属性和方法以及上层传入的命令，将数据处理为数据访问层需要的接口参数，并向数据访问层提交访问数据库的请求，并向业务接口层返回访问结果（实体层）；数据访问层会将数据转化为数据库可识别的语句（SQL），并访问数据库层，访问结果会返回给实体层（数据访问层）；数据库层处理上层传入的SQL，读写数据库内置对象，并根据其内置对象本身的关系对数据做进一步校验和处理（数据库层）。这里我所讲到的企业级数据库应用系统，不论它是基于B/S应用系统上的三层架构设计，还是基于C/S应用系统上的三层架构设计，基本上是一样的，所不同的只是两种方式常用的数据传输协议的不同，B/S应用系统设计一般数据传递是通过HTTP来完成的，C/S应用系统设计则更多的是基于TCP/IP协议来传送数据的，当然，随着企业级应用系统对安全性方面要求的要求越来越高，更多的防火墙架设于物理线路之间，C/S应用系统的设计也越来越多地趋向于HTTP

常见的三层架构基本包括如下几个部分，如图所示。

图常见的三层架构

l 数据访问层DAL：用于实现与数据库的交互和访问，从数据库获取数据或保存数据到数据库的部分。

2 业务逻辑层BLL：业务逻辑层承上启下，用于对上下交互的数据进行逻辑处理，实现业务目标。对于一些复杂的业务逻辑，循环算法  算法    异常通知 事件通知

Bl  业务逻辑层

循环 算法    异常通知 事件通知

 

  和表现层有关 的

  和SQL 语句有关的

 

Da  数据库访问 层 

  功能简单

 

3 表示层Web：主要实现和用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层去处理。功能比较单一，一些复杂的业务逻辑不能写在表现层，sql语句也不能写在表示层web里，如果把、sql语句写在表示层，会造成错误的！

日常开发的很多情况下为了复用一些共同的东西，会把一些各层都用的东西抽象出来。如我们将数据对象实体和方法分离，以便在多个层中传递，例如称为Model。一些共性的通用辅助类和工具方法，如数据校验、缓存处理、加解密处理等，为了让各个层之间复用，也单独分离出来，作为独立的模块使用，例如称为Common。

此时，所示。