发布于 由moslem

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

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

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

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

已读: 1,648

“数据访问层实现的一些个人想法”的13个回复

  1. 楼主指的musicland的方法只不过是没有看到他的数据库操作而以。近段也在看PetShop4，确实如楼上所说，数据库操作类太多的SQL语句和Parameter，总的来说PetShop还是不错的，musicland所用的方法似乎跟PetShop4差不多的。

    记得以前有人谈到过，PetShop4然后把数据访问层用NHibernate那样也许就是真正你想要的。
    另有人把PetShop3进行了重构，加入了Spring.Net和NHibernate，以前思归的博客上也提到过的。

  3. ModelInfo，瘦的业务实体数据对象？分离这么一个瘦的东西有多少好处呢？数据和操作分离？那不就是原始的“数据”+ “过程”的结构。
    我还是更习惯把ModelInfo和Model合并，除非有特别的需要。

  5. Enterprise Library怎么说呢.我们项目中用了EnterpriseLibraryJan2005.exe发现在C/S模式下还是可以.就是安装麻烦.甚至说是很麻烦,那里有产品做成这样的.数据库断了后可以自动连接.但是在B/S下麻烦可就大了.明明数据库可以连接.在长期运行后却报数据库不能打开的错误.以后所有的操作都会导致失败.痛苦.不知道楼主是否有心得.或者有解决办法.
    有对Enterprise Library研究的希望多交流.
    [email protected]

  6. 微软似乎一直不愿意让sql从业务代码中彻底消失。1和2做的还可以，3似乎不是很好

  7. 我觉得Enterprise Library还是很好用的。虽然是复杂了点，但是使用起来却不会太难，结合自带的Config工具进行配置文件的配置，使用起来已经非常方便了：）

  9. 说实话，实在没有想不通为什么SQLHelper 这么受欢迎。Data Access Application Block没使用过，不作评论。

    不管什么样的设计，选用ORM还是代码生成工具，还是sqlHelper之类的，最基本的原则，1去掉重复，用网友的话说：告别裸奔编码， 2，对修改封闭，对扩展开放，3，适合你这个team。从我的感觉来说，我不喜欢使用代码自动生成工具，因为既然能够用工具来生成代码，就说明代码背后有一定的逻辑，既然有一定的逻辑，那么就能够让一个引擎来解析，对于ORM工具，我比较赞同progame的看法，让ORM工具来处理一些繁琐的，重复性的工作，如果发现某一类代码重复出现了，再把它移到ORM或者叫做数据访问引擎中。不是要为了使用ORM，为了看起来像OO而去做OO的设计。

    在我的设想当中，有两个基础，一个是IDataAdapter，负责封装对数据的操作，只有简单的几个动作，GetValue，SetValue, Contains，比如ObjectAdapter，XmlAdapter，DictionaryAdapter，SqlParameterAdapter，WebControlAdapter等等，另一个是ICommandEngine，负责对动作封装，可以是class的一个方法，可以是Sql，可以是delegate，可以是一堆ICommandEngine。那么我们做的是把这一系列的数据和动作组合起来，对于组合的时候涉及的数据传递，应该采用自动发现的方式，比如根据一定的命名规则或者实现一个IMapping，我是采用数据层，Domain层，表现层采用相同命名的方法，也就是说项目中的任何一件事情，在项目所有的地方有一个统一的名字，这样的好处是省事，而且方便以后用metadata定义，比如验证方式，数据类型，默认控件，数据源。

    一个例子，Asp.Net的Web页面中要保存数据，可以写成这样的形式
    CallCommand("Update…", new WebControlContainAdapter(this) )

    对于一些面向对象中用继承来解决的一些问题，比如不同类型的order有不同的流程，不同的规则，我比较喜欢用Business Rule和Business Process来解决，Business Rule可以定义的很简单，每一个Rule Item全是And的关系，稍微复杂一点可以加上And Or和Exclude关系，基本可以解决一半的问题，更复杂的，可以用Expression，不过没有找到一个很好的Expression引擎，Business Process类似WorkFlow。

    我比较喜欢nant的方式，有很多内置的task，我们做的就是把这些Task组合起来，Task把一些繁琐的细节封装起来了，我们把自己从裸奔编码中解放出来，集中精力关注与怎么样把业务模型转化为代码模型。

  10. 楼上说得很好 复杂的东西如何简单化？ 并不是某个技术去一劳永逸地帮你简单化, 而是有人去非常痛苦地去实现一个复杂的东西 然后供使用者去组合，就像Nant，当然组合的方式是XML还是script，就另当别论了，XML可校验，但不易用，功能有限，script强大，易用，但无法100%校验。

    归根结底，重用是最重要的，相同的东西只能出现在一个地方，当你发现有相同的代码时，请封装到同一个功能体中，OO，SOA，用类的方式去思考，去建模，但是要用类似函数的方式去提供功能(尽量无状态，无依赖)。

  11. 顺大便多说一点 businessobject一定要和entiti object长得一样么， 我觉得没必要 BO中可定义主从关系，但我的entity完全可以相互独立 BO中也可以去定义继承关系， 不过entity可以完全不去管它，我觉得entity class是更帖近数据层的，而BO用它和数据层进行交互

  12. 实际中我习惯使用entity class，用DatabaseFacade类来负责数据库操作，有人说一个object为什么还要另外一个对象来负责他的CRUD之类持久化操作呢的，那么是不是这个object还要负责怎么样显示在UI中呢，还要负责长成什么样子呢。

  13. Pingback： H_J_H

  14. 我是新手，看了大家的发言，我有点儿迷糊了，我一直在用TableAdapter，并且认为它就是DAL，但看了大家的讨论，发现里面根本没提到TableAdapter, 是不是我理解错了?

评论已关闭。