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 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,无需其它操作等等。本来想在文中加入一些具体的代码的，但感觉不是很必要，如果大家觉得需要的话，我再补充吧。

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