疑惑之实体层

         我们在进行机房收费系统时，已经接触到三层及一些实例，但是三层到底是什么？我理解的三层是：UI---界面、BLL---逻辑层、DAL--数据层。但是在做实例时有一个实体层：Entity---实体层

         这就是我疑问的开始，为什么我们不叫做四层呢？实体层在三层中的作用是什么呢？带着这些疑问开始自己的学习之旅！ 各方高见:

        1.认为实体层只是一个辅助数据库映射

        2.认为Model就是一个载体，装到东西可以流走三层。这些冠名堂皇的解释让我还是云里雾里。实体层到底是什么？？              

那么以下就是我结合资料的理解：

        三层分别是脑袋，上肢，下肢，那Entity就是血液，流动在层次间的数据就像流动在肢体中的血液。虽然DataSet也可以当做数据载体而且效率高一些，但是Entity更有OO的感觉 。

接下来通过实例来理解实体层：

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

        这样，Entity在三层架构中的位置，和int，string等变量的地位就一样了，没有其它的目的，仅用于数据的存储而已，只不过它存储的是复杂的数据。所以如果你的项目中对象都非常简单，那么不用Entity而直接传递多个参数也能做成三层架构。

        那为什么还要有Entity呢？它的好处是什么呢？ Entity在各层参数传递时到底能起到多大的作用？接下来带着疑问进入思考：

    在各层间传递参数时，可以这样：

    AddUser（userId，userName，userPassword，…，）

    也可以这样：

    AddUser（userInfo）

    这两种方法那个好呢。一目了然，肯定是第二种要好很多。

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

    SelectUser（int UserId）

    SelectUserByName（string username）

    SelectUserByName（string username，string password）

    SelectUserByEmail（string email）

    SelectUserByEmail（string email，string password）

    可以概括为：

    SelectUser（userId）

    SelectUser（user）

        这里用user这个Entity对象囊括了username，password，email这三个参数的四种组合模式。UserId其实也可以合并到user中，但项目中其它BLL都实现了带有id参数的接口，所以这里也保留这一项。 传入了userInfo，那如何处理呢，这个就需要按照先后的顺序了，有具体代码决定。

       这里按这个顺序处理

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

       这样，如果以后增加一个新内容，会员卡（number），则无需更改接口，只要在DAL的代码中增加对number的支持就行，然后前台增加会员卡一项内容的表现与处理即可。 

        总结：通过以上总结我认为实体层就是一个在各层传递信息的载体，它可以让数据的传递变得简洁，并且不会让各种复杂参数混乱，让各层间的信息有序高效传递。