三层架构 之 一

http://www.cnblogs.com/xianspace/archive/2008/12/28/1364016.html

    一提三层架构，大家都知道是表现层（ UI ），业务逻辑层（ BLL ）和数据访问层（ DAL ），而且每层如何细分也都有很多的方法。但具体代码怎么写，到底那些文件算在哪一层，却是模模糊糊的。下面用一个简单的例子来带领大家实战三层架构的项目，这个例子只有一个功能，就是用户的简单管理。
    首先建立一个空白解决方案，添加如下项目及文件
    1 、添加 ASP.NET Web Application 项目，命名为 UI ，新建 Web Form 类型文件 User.aspx （含 User.aspx.cs ）
    2 、添加 ClassLibrary 项目，命名为 BLL ，新建 Class 类型文件 UserBLL.cs
    3 、添加 ClassLibrary 项目，命名为 DAL ，新建 Class 类型文件 UserDAL.cs 。添加 SQLHelper 引用。（这个是微软的数据访问类，也可以不用，直接编写所有的数据访问代码。我一般用自己写的数据访问类 DataAccessHelper ）。
    4 、添加 ClassLibrary 项目，命名为 Model ，新建 Class 类型文件 UserModel.cs
    5 、添加 ClassLibrary 项目，命名为 IDAL ，新建 Interface 类型文件 IUserDAL.cs
    6 、添加 ClassLibrary 项目，命名为 ClassFactory
    相信大家已经看出来了，这个和 Petshop 的示例没什么区别，而且更简单，因为在下也是通过 Petshop 学习三层架构的。但一些朋友对于这几个项目所处的层次，以及它们之间的关系，可能比较模糊，这里逐个说明一下：
    1 、 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 才算有了真正的用途。
    2 、 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 中也就有了逻辑处理的代码。
    3 、 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 的支持就行，然后前台增加会员卡一项内容的表现与处理即可。 
    4 、 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 ，一个可以随意弃置的部分，又怎么能成为三层架构中的一层呢。
    可以这样定义：与数据源操作有关的代码，就应该放在数据访问层中，属于数据访问层
    5 、 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 ，无需其它操作等等。本来想在文中加入一些具体的代码的，但感觉不是很必要，如果大家觉得需要的话，我再补充吧。
    总结：不要因为某个层对你来说没用，或者实现起来特别简单，就认为它没有必要，或者摒弃它，或者挪作它用。只要进行了分层，不管是几层，每一层都要有明确的目的和功能实现，而不要被实际过程所左右，造成同一类文件位于不同层的情况发生。也不要出现同一层实现了不同的功能的情况发生。