ASP.NET三层架构

 本文不是从理论的角度来探讨三层架构，而是用一个示例来介绍如何建设一个三层架构的项目，并说明项目中各个文件所处的层次与做用。写本文的目的，不是为了说明本身的这个方法有多对，别人的确定不对，而是但愿给那些初学三层架构殊不知从何入手的朋友提供一点帮助。由于网上的文章，大可能是注重理论的介绍，而忽略了具体的实践应用，或者有示例但讲得不透彻。致使看了以后，理论上又学习了一遍，但仍是不知道代码怎么写。因此想从这个方面入手写一下，让历来没作过三层架构的初学者也能照猫画虎，写出代码来。文章表述的是笔者我的对三层架构的认识，确定有许多不足的地方，欢迎你们指正，小弟也会根据反馈来修改这篇文章。文中的代码是伪代码，仅用来阐明思路。

    正文：

    一提三层架构，你们都知道是表现层（UI），业务逻辑层（BLL）和数据访问层（DAL），并且每层如何细分也都有不少的方法。但具体代码怎么写，到底那些文件算在哪一层，倒是模模糊糊的。下面用一个简单的例子来带领你们实战三层架构的项目，这个例子只有一个功能，就是用户的简单管理。

    首先创建一个空白解决方案，添加以下项目及文件

 

一、添加ASP.NET Web Application项目，命名为UI，新建Web Form类型文件User.aspx（含User.aspx.cs）

 

二、添加ClassLibrary项目，命名为BLL，新建Class类型文件UserBLL.cs

 

三、添加ClassLibrary项目，命名为DAL，新建Class类型文件UserDAL.cs。添加SQLHelper引用。（这个是微软的数据访问类，也能够不用，直接编写全部的数据访问代码。我通常用本身写的数据访问类DataAccessHelper ）。

 

四、添加ClassLibrary项目，命名为Model，新建Class类型文件UserModel.cs

 

五、添加ClassLibrary项目，命名为IDAL，新建Interface类型文件IUserDAL.cs

 

六、添加ClassLibrary项目，命名为ClassFactory

 

相信你们已经看出来了，这个和Petshop的示例没什么区别，并且更简单，由于在下也是经过Petshop学习三层架构的。但一些朋友对于这几个项目所处的层次，以及它们之间的关系，可能比较模糊，这里逐个说明一下：

 

一、User.aspx和User.aspx.cs

 

这两个文件（以及文件所属的项目，下面也是如此，再也不重复强调了）都属于表现层部分。User.aspx比较好理解，由于它就是显示页面了。User.aspx.cs有些人以为不该该算，而是要划到业务逻辑层中去。若是不作分层的话，那么让User.aspx.cs来处理业务逻辑，甚至操做数据库都没什么问题，可是作分层的话，这样就不该该了。在分层结构中，User.aspx.cs仅应该处理与显示有关的内容，其它部分都不该该涉及。

 

举例：咱们实现用列表方式显示用户的功能，那么提取信息的工做是由BLL来作的，UI（本例中是User.aspx.cs）调用BLL获得UserInfo后，经过代码绑定到User.aspx的数据控件上，就实现了列表的显示。在此过程当中User.aspx.cs对UI没有起到什么做用，仅是用来传递数据，并且由于实际编码中大部分状况都是如此的实现，因此使有些人以为User.aspx.cs不该该算UI，而应该并入BLL负责逻辑处理。继续往下看，这时提出了一个新需求，要求在每一个用户的前面加一个图标，生动地表现出用户的性别，并且不满18岁的用儿童图标表示。这个需求的实现，就轮到User.aspx.cs来作了，这种状况下User.aspx.cs才算有了真正的用途。

 

二、NewBLL.cs

 

添加以下方法：

 

public IList<UserInfo> GetUsers()：返回全部的用户信息列表

 

public UserInfo GetUser(int UserId)：返回指定用户的详细信息

 

public bool AddUser(UserInfo User)：新增用户信息

 

public bool ChangeUser(UserInfo User)：更新用户信息

 

public void RemoveUser(int UserId)：移除用户信息

 

此文件就属于业务逻辑层了，专门用来处理与业务逻辑有关的操做。可能有不少人以为这一层惟一的用途，就是把表现层传过来的数据转发给数据层。这种状况确实不少，但这只能说明项目比较简单，或者项目自己与业务的关系结合的不紧密（好比当前比较流行的MIS），因此形成业务层无事可作，只起到了一个转发的做用。但这不表明业务层无关紧要，随着项目的增大，或者业务关系比较多，业务层就会体现出它的做用来了。

 

此处最可能形成错误的，就是把数据操做代码划在了业务逻辑层，而把数据库做为了数据访问层。

 

举例：有些朋友感受BLL层意义不大，只是将DAL的数据提上来就转发给了UI，而未做任何处理。看一下这个例子

 

BLL层

 

SelectUser（UserInfo userInfo）根据传入的username或email获得用户详细信息。

 

IsExist（UserInfo userInfo）判断指定的username或email是否存在。

 

而后DAL也相应提供方法共BLL调用

 

SelectUser（UserInfo userInfo）

 

IsExist（UserInfo userInfo）

 

这样BLL确实只起到了一个传递的做用。

 

但若是这样作：

 

BLL.IsExist（Userinfo userinfo）

 

{

 

      UerInfo user = DAL.SelectUser（User）；

 

 

return (userInfo.Id != null);

 

}

 

那么DAL就无需实现IsExist()方法了，BLL中也就有了逻辑处理的代码。

 

三、UserModel.cs

 

实体类，这个东西，你们可能以为很差分层。包括我之前在内，是这样理解的：UIßàModelßàBLLßàModelßàDAL，如此则认为Model在各层之间起到了一个数据传输的桥梁做用。不过在这里，咱们不是把事情想简单，而是想复杂了。

 

Model是什么？它什么也不是！它在三层架构中是无关紧要的。它其实就是面向对象编程中最基本的东西：类。一个桌子是一个类，一条新闻也是一个类，int、string、doublie等也是类，它仅仅是一个类而已。

 

这样，Model在三层架构中的位置，和int，string等变量的地位就同样了，没有其它的目的，仅用于数据的存储而已，只不过它存储的是复杂的数据。因此若是你的项目中对象都很是简单，那么不用Model而直接传递多个参数也能作成三层架构。

 

那为何还要有Model呢，它的好处是什么呢。下面是思考一个问题时想到的，插在这里：   

 

Model在各层参数传递时到底能起到作大的做用？

 

在各层间传递参数时，能够这样：

 

AddUser（userId，userName，userPassword，…，）

 

也能够这样：

 

AddUser（userInfo）

 

这两种方法那个好呢。一目了然，确定是第二种要好不少。

 

何时用普通变量类型（int,string,guid,double）在各层之间传递参数，什么使用Model传递？下面几个方法：

 

SelectUser（int UserId）

 

SelectUserByName（string username）

 

SelectUserByName（string username，string password）

 

SelectUserByEmail（string email）

 

SelectUserByEmail（string email，string password）

 

能够归纳为：

 

SelectUser（userId）

 

SelectUser（user）

 

这里用user这个Model对象囊括了username，password，email这三个参数的四种组合模式。UserId其实也能够合并到user中，但项目中其它BLL都实现了带有id参数的接口，因此这里也保留这一项。

 

传入了userInfo，那如何处理呢，这个就须要按照前后的顺序了，有具体代码决定。

 

这里按这个顺序处理

 

首先看是否同时具备username和password，而后看是否同时具备email和password，而后看是否有username，而后看是否有email。依次处理。

 

这样，若是之后增长一个新内容，会员卡（number），则无需更改接口，只要在DAL的代码中增长对number的支持就行，而后前台增长会员卡一项内容的表现与处理便可。

 

四、UserDAL.cs

 

public IList<UserInfo> SelectUsers()：返回全部的用户信息列表

 

public UserInfo SelectUser(int UserId)：返回指定用户的相信信息

 

public bool InsertUser(UserInfo User)：新增用户信息

 

public bool UpdateUser(UserInfo User)：更新用户信息

 

public void DeleteUser(int UserId)：移除用户信息

 

不少人最闹不清的就是数据访问层，到底那部分才算数据访问层呢？有些认为数据库就是数据访问层，这是对定义没有搞清楚，DAL是数据访问层而不是数据存储层，所以数据库不多是这一层的。也有的把SQLHelper（或其同类做用的组件）做为数据访问层，它又是一个无关紧要的东西，SQLHelper的做用是减小重复性编码，提升编码效率，所以若是我习惯在意效率或使用一个非数据库的数据源时，能够丢弃SQLHelper，一个能够随意弃置的部分，又怎么能成为三层架构中的一层呢。

 

能够这样定义：与数据源操做有关的代码，就应该放在数据访问层中，属于数据访问层

 

五、IUserDAL

 

数据访问层接口，这又是一个无关紧要的东西，由于Petshop中带了它和ClassFactory类工厂，因此有些项目不论需不须要支持多数据源，都把这两个东西作了进来，有的甚至不建ClassFactory而只建了IDAL，而后“IUserDAL iUserDal = new UserDAL();”，不知意义何在。这就彻底是画虎不成反类犬了。

 

许多人在这里有一个误解，那就是觉得存在这样的关系：BLLßàIDALßàDAL，认为IDAL起到了BLL和DAL之间的桥梁做用，BLL是经过IDAL来调用DAL的。但实际是即便你如此编码：“IUserDAL iUserDal = ClassFacotry.CreateUserDAL()；”，那么在执行“iUserDal.SelectUsers()”时，其实仍是执行的UserDAL实例，而不是IUserDAL实例，因此IDAL在三层中的位置是与DAL平级的关系。

 

经过上面的介绍，基本上将三层架构的层次结构说明了。其实，本人有一个判断三层架构是否标准的方法，那就是将三层中的任意一层彻底替换，都不会对其它两层形成影响，这样的构造基本就符合三层标准了（虽然实现起来比较难^_^）。例如若是将项目从B/S改成C/S（或相反），那么除了UI之外，BLL与DAL都不用改动；或者将SQLServer改成Oracle，只需替换SQLServerDAL到OracleDAL，无需其它操做等等。原本想在文中加入一些具体的代码的，但感受不是很必要，若是你们以为须要的话，我再补充吧。

 

总结：不要由于某个层对你来讲没用，或者实现起来特别简单，就认为它没有必要，或者摒弃它，或者挪做它用。只要进行了分层，无论是几层，每一层都要有明确的目的和功能实现，而不要被实际过程所左右，形成同一类文件位于不一样层的状况发生。也不要出现同一层实现了不一样的功能的状况发生。