此处最可能造成错误的，就是把数据操作代码划在了业务逻辑层，而把数据库作为了数据访问层。
    举例：有些朋友感觉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的支持就行，然后前台增加会员卡一项内容的表现与处理即可。