今天我们来探讨BLL层（业务逻辑层）与DAL层（数据访问层）之间的数据传递方式。
如果你以前编写过三层架构，那么一定很熟悉下面的几种BLL层与DAL层的数据传递方式：
DataReaders
DataSet
类型的DataSet
自定义实体类
标量值
第一个是dataReaders。datareader是一个速度非常快而且是一次性加载数据的对象。通过他的一些方法和属性，可以很轻易的获取他的数据。但是他也有不少的缺点，一个是他必须要在连接数据库的状态下才可以读取数据，这样就造成了有可能在我们读取完数据之后忘记把数据库关上，从而导致其他用户无法连接数据库。因此必须显式的关闭数据库连接。第二个缺点是他是只读的，就是说我们不可以直接从datareaders中读取数据后再把数据更新到数据库中，如果要更新数据的话就必须选择其他途径来更新。第三个缺点是他不是强类型的，就是说他没办法检测数据的类型，这样就有可能造成在数据的传递过程中出现类型匹配错误，而我们的编译器又往往在这些地方很难检测到这些不是强类型的错误。
第二个是DataSet。DataSet可以说是数据库表在内存中的一个投影。他跟数据源是完全无连接的，只要数据已加载进DataSet中，他跟数据源就没有任何的连接了的。因为他是无连接的，所以你不必担心程序会关闭数据连接。同时DataSet支持增加、更改、删除数据。你也可以用DataSet代表复杂数据和代表关联数据。同时，DataSet跟datareader一样，他们都不是强类型的，因此当你使用DataSet的时候就必须确定每一个字段的类型是否正确的匹配。而且DataSet比datareader的开销要大，因为他返回了更多关于底层数据表的信息。
第三个是类型化的DataSet。类型化的DataSet就是指使用DataSet来做底层的数据结构再在DataSet中加入强类型，让调用者更容易的访问数据，更加容易阅读代码。这意味着你可以使用智能感应开发工具开发你的项目。强类型同样意味着他提供编译时检测，而不是运行时检测。虽然类型化的DataSet非常的cool，但我不打算使用强类型的DataSet，如果你继续阅读下去，你会发现有更多的更cool的类型代表数据表。当然类型化的DataSet也有缺点，就是当底层数据表发生变化时，我们必须重新改写我们创建的DataSet。
第四个是自定义实体类，自定义实体类是用户根据数据库而建立的类，通常我们都创建属性来代表每一个字段，然后用list或者arraylist来记录一张表的记录。如果我们使用自定义实体类来传递数据，我们一般会采用datareader来读取数据库中的记录，然后赋值到自定义实体类中，再把自定义实体类传递到BLL层（业务逻辑层）中去。这样我们就可以把数据连接放在DAL层中管理，这是一件好事情。同样，我们也可以用结构，而不是类来代表数据，因为结构是值类型的，所以结构的开销要比类更加少。自定义实体类让程序更加容易阅读，而且他支持智能感应开发，因为他是强类型的。
自定义实体类的缺点是我们必须手动的去创建他们，当我们做一个项目时，我们会发现创建实体类的这一部分工作会变得枯燥无味，因为都是些机械的动作。这时我们可能转去使用工具来创建实体类，但这样往往又会增加项目的复杂度。另外，当底层表发生变化时，自定义实体类也必须跟着变化。自定义实体类是跟datareader打交道的，因此他的类型检测会推迟到运行时，这样就迫使我们必须确定我们的实体类跟数据表分毫无差的匹配了。
最后一个我要介绍的是标量值。当我们想要增加、更新、删除数据的时候，我们可以传递单独的字段到DAL层中。使用标量值的性能会比使用其他类型要更加高，因为他是简单的值类型。不过标量值使用起来并不那么的方便，在代表数据库中的表时显得格外的尴尬。