简单的三层架构及思想，总结（适合简单框架搭建）

从毕业到现在，从事软件行业不过两三年，但大大小小项目也做了几个，对于大项目，只能在自己的模块中比较了解，而对于整体的大框架，都是专家或架构师级别设计搭建的，但有好多小项目，基本都是个人完成的，所以在这里总结一下个人领悟.

做.NET的童鞋们应该对三层架构都了解，也是最基本的项目框架， 但好多人或初学者就只认为三层架构就是三个类库，即表示层、业务逻辑层、数据访问层。

其实三层只是个大的概括，就像MVC模式一样，看你怎么拓展了。经过看一下系统搭建方面的书籍，以及NHibernate和EntityFramework这些ORM模型框架的机制的初步了解，最近做的两个小项目都使用了我自己搭建的简单的多层框架（三层架构的扩展）。

首先还是三大层： 表示层、逻辑层、数据访问层。

     表示层：页面（html、asp）、页面逻辑。

逻辑层：页面和数据访问层的桥梁。

数据访问层：主要是ADO.NET对数据库的操作。

实体模型：页面实体模型和数据库实体模型。

以上是对框架的分层，下面说说具体每层的职责功能：

数据模型分了两种，一个是和页面相关的，做.net的都知道， 微软封装了好多控件， 控件就有绑定的功能， 为了能够满足页面对数据的要求，所以，定义一个页面级的实体模型，需要什么类型就定义一个类型。比如，一个student 本身不包含班级和学校的信息， 但是页面上要显示一个学校班级学生的整体信息，那么我们就可以定义这么一个类，将student类、class类、school类中的字段封装进去，这样就方便页面的绑定或者其它操作了。

还有一个是数据库实体模型，这个是看到ORM里面使用的，就是一个实体对应一个数据库的表中的所有字段，以及他们的依赖关系。只要数据库搭建的合理，那么他们的关系也就自然清晰，一目了然，也就更容易维护和扩展了。

数据访问层：只负责对数据库的增删改查操作， 不涉及业务逻辑的处理。这样使得该数据层可以被多个上层重复使用。只和数据库中紧紧关联。

业务逻辑层：业务逻辑的处理，涉及到项目的业务功能流程的操作就在该层处理，比如：先添加一条记录到A表，然后再删除B表中的一条记录等等， 这些业务流程的功能就在业务逻辑层实现，不要再数据访问层里。同时，业务逻辑层还有一个工作就是将数据访问层查询的结果数据转换成页面所需要的类型。它返回该页面层的就是页面层所需要的数据集。

表示层逻辑：ASP.net的aspx引擎是有页面为入口点的， 不像jsp或razor引擎是通过控制器来访问的，所以，在页面里写太多数据处理会让人看得很晕，所以，比如从textbox中获取的string类型的值转换成int型等一些数据处理的工作就放到页面逻辑类的代码里面。这样在aspx后置代码里面会显得很清爽。

当然，层与层之间最好通过接口来通信。保持高内聚，低耦合的原则。此外还有一些共通的处理的抽取等等就不说了，这里只总结一下对各层的划分的总结。