面向对象数据库编程

Question

将业务逻辑和界面分离我觉得一个难办的问题在于如果要使用 DBGrid 来作为显示记录的工具，这个时候，这个 DBGrid 的数据怎么提取呢？
难道还用 TADOQuery 来取吗？这样会不会破坏业务对象的封装？象《Delphi 面向对象思想》中那样，从 TClientDataSet 中继承而来的业务数据集对象，还是需要一个用来保存字段信息的类（或者是 Record） ，这样一来还是会很麻烦。不知道大家在把业务逻辑和界面分离的时候都怎么处理的
好困惑啊

Answer 1

如果要用到 面向对象数据库编程 , 感覺就不應該用數據感應類控件, 但實際上, 這樣給編程帶來很多麻煩!有一種比較好的實現思路, 你可參考delphi2005 帶的 ECO II, 看看相關的文章

Answer 2

我一般不使用 除 DBGrid 之外的 感应控件的，但如果不用 DBGrid 恐怕不太好吧？

Answer 3

用 TADOQuery 应该没问题

Answer 4

比如我们都把相关的业务处理功能都放到类 中了，那当然从数据库提取记录集也应该是这个业务类的一部分了，这个时候我们再让 DBGrid 从 TADOQuery.DataSet 中得到记录集，不是将封装性打破了么？

Answer 5

你让你的类返回数据集就行了，DBGrid用这个数据集。

Answer 6

eco和ormapping差不多。eco的rad做得不很好，控制比较麻烦，不灵活。

Answer 7

不了解 eco 为何物,汗！

Answer 8

我理解的业务类应该高于数据库表，比如可能会从多个表中读取数据感觉将业务类封装好后，在界面中的记录读取和更新不太方便。
而且我一直不太明白应该怎么取得业务类的记录集，对 TClientDataSet 不太熟练，而其他的 TADOQuery 之类的好像不太好用

Answer 9

to Rail100我最近为什么总在找关于业务封装的内容看呢，就是因为不封装的话，很多问题很难控制，当系统大到一定的程度，维护起来及其困难所以我感觉封装的必要性啊，封装了，那么不用考虑系统中其他的对这部分业务关于数据库的引用了，思路都会会清晰很多，否则，出了一个需要修改的地方，就的找死你就像我将登录部分封装一样，之后在其他地方就不必考虑任何关于系统用户和权限的管理问题，方便多了。所以，封装毫无疑问是必要的。
但怎么封装好业务对象，这个确实需要一定经验的啊，希望大家都讨论
我现在正在试用 ClientDataSet 作为界面中的 DataSet ，然后在业务对象中通过 TDataSetProvider 来输出 Data 。一定将相关经验和问题同大家一块讨论

Answer 10

封装业务对象后，怎么修改业务的记录集成了我现在的一个问题，首先，需要使用 DBGrid 控件，使用多了，其他的感应控件可以不用，这个不用实在难受如果使用了 DBGrid ，利用那种 DataSet 给它提供数据是个问题，因为你使用 一般的 Query 控件，肯定会在业务对象外和数据库打交道，失去了封装的意义，不行的所以，看到那些关于三层开发的帖子，可以使用 TClientDataSet.Data 来从 TDataSetProvide.data 接收数据。我现在试到了 ApplyUpdates 的错误这一块了，好像很多人碰到过这个问题

Answer 11

注意，一定得通过 ClientDataSet.Data=业务对象.得到数据集 的方法来给 ClientDataSet 赋值，不能利用 ClientData.CommandText，也不能使用 ClientData.ProviderName ，因为不能将业务对象的 Provider 暴露出来啊

Answer 12

也就是说 客户端的 ClientDataSet 仅仅负责得到数据，修改之后将结果集提交给 业务对象的 Provider 来进行更新，因此，不能够在 ClientDataSet 过多的进行其他的处理看到很多网友提示可以在 ClientDataSet.OnReconcileError 中查看错误信息，
但我发现，如果是通过 ClientDataSet.Data 进行赋值的话，因为并没有通过 客户端的 ClientDataSet 进行数据的提交更新，因此，应该在业务对象中的 Provider 来查看错误信息，是下面这个事件：DataSetProvider.OnUpdateError 这个事件和 ClientDataSet.OnReconcileError 事件的参数很类似
我现在的错误信息是 "违反了表的关键字约束，不能插入重复键" (大概意思)
可我并不是新增啊，我是在 ClientDataSet 中更改了某条记录，然后通过Provider.ApplyUpdates(ClientDataSt.Data,0,ErrCount);来进行更新

Answer 13

to 搂住：
>把业务逻辑和界面分离的时候都怎么处理的
业务逻辑和DataSet没有关系，DataSet只是Delphi用于数据访问的通用接口。Data如果得到，和业务逻辑没有关系，是另外一个问题

Answer 14

to alphax我在想：如果不需要业务对象提供记录集给客户使用，那么，客户的独立封装是很容易做得到的
可真是需要提供记录集给客户端的 DataSet 使用，显然：1. 怎么从业务对象取得记录集给客户端
2. 怎么根据客户端的记录集的更改而来修改业务对象的数据（反映到数据库）这便是我认为的需要处理的两个问题而 ClientDataSet 和 DataSetProvider 恰恰满足了这两个要求1. 在业务对象中返回 DataSetProvider.Data 给客户端的 ClientDataSet.Data 使用
2. 通过 DataSetProvider.ApplyUpdates(ClientDataSet.Data,0,out ErrCount) 来修改到数据库对于第一个是比较容易的，而对于第二个则需要注意相关的属性设置，不太容易

Answer 15

个人觉得用DataSetProvider.ApplyUpdates()来操作数据库并不灵活

Answer 16

C/S系统这么搞没多大意思，你先从DataSetProvider那里得到Data，然后复制到界面上的ClientDataSet.Data，最后还是变成DataSet传给DBGrid，有什么意义？徒然浪费内存和cpu时间而已DBGrid需要的是TDataSource，你给他一个DataSource不就完事了？一个现实的系统，不可能什么都完全封装，任何一个环节都不可能对它所涵接的环节一无所知的，必定有已知、已经确定的东西，只是将这些已知的东西尽量限制在仅仅是必需的范围内而已。而且，封装、抽象，最关键的是整个系统的抽象，大粒度、高层次的抽象和封装，细枝末节的东西，即使有变动也是局部而已，不会有多大影响的我在borland的qc/newgroups上看到一些贴子，很多Delphi爱好者本着对Delphi的热爱，向borland提出了很多关于delphi的增进的建议，有些贴子真的可以看到一些爱好者已经到了狂热的地步，但是borland方面的回答——Delphi是一个通用开发工具，Delphi的目标是RAD，不是编译器，也不是用来建造基础设施的工具，Delphi重在rapid这个字，所谓的通用，说的只是可以拿来快速开发出各种各样的应用，你选择了Delphi，意味着你选择了快速