数据访问层实现的一些个人想法

个人感觉数据访问层应该实现以下几个主要目的：

1） 分离业务层与数据层

2）屏蔽具体数据库的差异（如SQLServer、Oracle、OLEDB、ODBC等）

3）简化数据访问层的代码，经常写一些 Parameter 的设定是很无聊的事情）

先下载并研究了一下Enterprise Library 2.0 ，发现其中的Data Access Application Block有点复杂了，有近 40 个类文件，还需要引用 Configuration、Common、ObjectBuilder 等项目，本身就是一个很大的项目了... 个人觉得还不如上一个版本中的 SQLHelper 对象那么简单方便（Pet Shop 4.0 中的 DabaAccess 项目里就是用 OracleHelper和SQLHelper来实现的）

再来研究Pet Shop 4.0 ，其中主要对象层次一般是（假设Model是业务对象）：

ModelInfo <- Model -> IDAL <- SQLServerDAL(或OracleDAL)

其中：

• ModelInfo 是瘦的业务实体数据对象
• Model 实现 ModelInfo 的管理（增、删、改、查询）等，调用 IDAL 来实现
• IDAL 是数据访问层的接口定义
• SQLServerDAL 是 IDAL 在 SQLServer 上的实现，如果是 Oracle，可以利用 OracleDAL 来实现

貌视还不错的结构，只是 DAL 层的里面的代码还是比较多，好多SQL、好多Parameter的操作

再看看 Visual Studio 2005 中带的"个人网站的初学者工具包"的数据访问代码，它只是简单在App_Code中有 Model(瘦的业务实体数据对象)、ModelManager(管理对象，数据层的访问也在其中实现)的两个对象，数据库也只是SQL Server，较为简单，但也不易扩展。

我的一点想法：

1）Enterprise Library 2.0 有些庞大和重量级，学习曲线太长，谨慎使用

2）Visual Studio 2005 中的数据集对象（DataSet）是个好东西，可以简化很多SQL语句的编写和参数的设定

3）Pet Shop 4.0 的总体架构还是不错的（Model <- ModelInfo -> IDAL <- SQLServerDAL），值得参考，但是在SQLServerDAL 和 OracleDAL 不用手动去编写代码，而是调用利用 DataSet 自动生成的代码来实现（SQLServer、Oracle、OLEDB或ODBC等），简单的业务对象管理动作应該是能直接利用DataSet提供的方法直接实现，如果是复杂的数据层操作，可以自己编写代码来实现（如多个表之间的数据操作）

4）musicland 和 JGTM 2006 也提供了一种不错的实现方式，具体参考这篇Post

这样的话，开始提到的三个目的都能达到了。

 

http://blog.joycode.com/moslem/archive/2006/08/22/81210.aspx