1.在基于DELPHI的面向对象系统中，对数据库操作应如何进行静态和动态设计？
不知大家有否注意到，如果完全使用面向对象形式对数据库系统进行构造，则在使用时会产生大量的对象实例，因为“一类一表”结构所对应的应该是“一记录一对象实例”，即便使用“懒对象”，如果同时操作的记录一多，其实例数量也会相当惊人，而且用此方法又如何对检索后的数据进一步检索呢（难道非得放着SQL不用，而用手工检索吗？）
DELPHI提供的TQUERY/TTABLE等控件是基于“一对象一表”的，但我不清楚是否真的能用这种结构进行面向对象设计，还是只能把它作为一个用于检索或生成视图的工具类？所以我想问一下大家在DELPHI中是如何进行“面向对象”数据库系统设计的？（还是依然在使用面向过程设计？又是如何对系统中其它的“类”进行协作？我这次依然使用了面向过程方式，但没有找到从面向对象到面向过程的映射关系）一个简单的例子：一个组管理多个用户，一个用户只能加入一个组；一个组拥有一组资源，一个资源只属于一个组；一个组可以有多个子组，每个子组也可以有多个父组；子组的资源对父组是公开的（继承关系）。
系统要求的操作是：得到某个用户所能使用的所有资源。面向对象设计的静态结构（一类一表）：
+-----+
* | | +--------+
+------+ * 1 +----+ * |----| 组继承 |
| 资源 |-------| 组 |---+ +--------+
+------+ +----+
| 1
| *
+------+
| 用户 |
+------+
面向过程（大部分管理细节由动态结构定义，也不能表现出数据库结构，但实例数少得多）：
+--------+ 1 * +--------+ 1 1 +--------------+
|用户管理|-----|活动用户|-------|用户可用资源集|
+--------+ +--------+ +--------------+--------------------------------------------------------------------------2.我在对一张多通道板卡进行上层包装时，注意到多数情况下，DELPHI的容器类控件会把事件指针放在子类中（也就是子类中有自己独立的事件），但如果我把它提到容器中也应是可以的（也就是多个子对象共用一个容器事件，事件参数中包含子对象引址），这样对面向对象软件设计来说只是在结构中多了一个“关联类”，但对面向过程的编程来说可以方便很多。所以我想问一下，一般大家对此类包装会更倾向于哪一种形式？为什么？
不知大家有否注意到，如果完全使用面向对象形式对数据库系统进行构造，则在使用时会产生大量的对象实例，因为“一类一表”结构所对应的应该是“一记录一对象实例”，即便使用“懒对象”，如果同时操作的记录一多，其实例数量也会相当惊人，而且用此方法又如何对检索后的数据进一步检索呢（难道非得放着SQL不用，而用手工检索吗？）
DELPHI提供的TQUERY/TTABLE等控件是基于“一对象一表”的，但我不清楚是否真的能用这种结构进行面向对象设计，还是只能把它作为一个用于检索或生成视图的工具类？所以我想问一下大家在DELPHI中是如何进行“面向对象”数据库系统设计的？（还是依然在使用面向过程设计？又是如何对系统中其它的“类”进行协作？我这次依然使用了面向过程方式，但没有找到从面向对象到面向过程的映射关系）一个简单的例子：一个组管理多个用户，一个用户只能加入一个组；一个组拥有一组资源，一个资源只属于一个组；一个组可以有多个子组，每个子组也可以有多个父组；子组的资源对父组是公开的（继承关系）。
系统要求的操作是：得到某个用户所能使用的所有资源。面向对象设计的静态结构（一类一表）：
+-----+
* | | +--------+
+------+ * 1 +----+ * |----| 组继承 |
| 资源 |-------| 组 |---+ +--------+
+------+ +----+
| 1
| *
+------+
| 用户 |
+------+
面向过程（大部分管理细节由动态结构定义，也不能表现出数据库结构，但实例数少得多）：
+--------+ 1 * +--------+ 1 1 +--------------+
|用户管理|-----|活动用户|-------|用户可用资源集|
+--------+ +--------+ +--------------+--------------------------------------------------------------------------2.我在对一张多通道板卡进行上层包装时，注意到多数情况下，DELPHI的容器类控件会把事件指针放在子类中（也就是子类中有自己独立的事件），但如果我把它提到容器中也应是可以的（也就是多个子对象共用一个容器事件，事件参数中包含子对象引址），这样对面向对象软件设计来说只是在结构中多了一个“关联类”，但对面向过程的编程来说可以方便很多。所以我想问一下，一般大家对此类包装会更倾向于哪一种形式？为什么？
学的不是很好呀
下次我会给你一个好的答案的呀
真的呀
这2个问题应该不仅仅只是DELPHI才有的呀!
我现在更习惯于用UML建模,但问题在于对建模的技术还不熟练,更是很难使之与面向过程的实现相配合,我想关系数据库应该是目前应用最多,也是最直接的切入手段了吧...请大家多谈谈啊!
首先我很感谢你的回答.
但对第一个问题,可能你还没明白我的意思.我是指如果我把DataSet的每条记录看成一个对象,那么就出现了一个问题:记录是没有可执行方法的!但在实际建模时(特别是用面向对象思路建模时),对象的方法已经被有意无意地用了进去(就如同'组'中必然会包含对'用户'和'资源'的管理方法.而且,如果你把这些方法从这些类中独立出来,那么实际上你是在用面向过程的方法在建模,更重要的是,你将不可能再使用标准的数据库系统建模方法,这点如果你看过UML的相关书籍应该会了解,至少我到现在还找出不其它方法).所以我就是想了解,现在大家是如何去做的?又是如何对数据库系统地行合理建模的,特别是在DELPHI中又是如何实际运用的?我也想说一点,其实我并不是为了面向对象而去构造对象,而是为了把逻辑模型映射为实现代码而不得不这样做.(但实际上我没有这样做,因为我做不到--不知道如何合理地做,所以我实际上还是在用面向过程在开发--只不过是用了面向对象的外壳而已!)
能否给个例子?我可以先举例说明一下我的观点:
[组]----[用户] // 一个组管理一群用户
"组"会有一些基本属性和方法:
User[Index] : TUser; // 用户列表
UserCount : integer; // 用户数量
Add : TUser; // 增加一个用户
Delete(Index: integer); // 删除一个用户
Search(...) : TUser; // 查找某个(或多个)用户当然,我们完全可以用一个单独的类来实现上面这些方法(因为现在组和用户都不能有方法),于是我就得把模型改成下面的形式:
[组集]--[管理器]--[用户集] // 注意:这里只有一个组集和一个用户集,对应的管理器包含了上面所有的方法(功能)
因为组集中有未知多个组,而每个组又有未知多个用户,所以用户集的数量不可能是动态的多个(只能是一个,如果是多个,则会使得管理器变得很盲从,因为管理器不知道那个组对应哪个用户集).这就出现了一个问题:我们必须依照使用中的'组'来动态地用SQL(或别的方法)更新'用户集'的数据!----这样尽管我们还是在用面向对象外壳,但模型实际上已经是在用面向过程的方法了!(没有了面向对象建模的根本要素----功能内聚)我想问的就是:有没有第三种更好的解决方案了?
能给出例子吗？最好就用最上面那个简单的题目
简单的讲就是 根本不需要一类一表， 一类可以多表， 一表可以多类
我没用过delphi， 不知道dataset是怎么回事，但我觉得，RAD的开发工具带来快捷性的同时，也失去了灵活性。
我觉得在需要系统良好架构的时候，不要采用数据绑定技术，建议看看.net的dataset,个人觉得很好
我知道你的意思了,你是说把DataSet的每个记录看成一个对象,但使用时并不去生成实体对象,而就是用DataSet自己的记录,是不是?
但实际上你并没有回答我的问题,我问得就是:如何用你这种方法来建模?我是指建模,而不是使用!或都说,如何把前面的"标准"模型,映射为这种模型,我没有找到方法!to qiujoe:
面向对象完全可以用来设计数据库的,而且在某些方面比ER模型更有效更直观,最主要的就是可以直接与系统相集成,只是因为面向对象建模方法更适用于面向对象数据库,而对于关系模型,则要经过结构映射后才能使用.我没用过.net,但我想它应该用DELPHI的差不多,也就是一对象一表结构(数据集/记录集).事实上我知道确实有一种模型可以很好地实现我们的要求(因为我听说过),但我找了大量的书籍资料和网站,就是找不到这种建模方法!
我还要说明一点,就是面向对象的核心是内聚和封装,如果于应该是由此对象来完成的方法而没有用些对象来完成,那就不能算是一个真正的面向对象系统了!(当然我不认为真正的面向对象就一定好,但有一点,如果这样做,会使得复杂系统的设计变得简单得多!)
而按现在的解决办法是：DataSet.Seek ( '姓名=张三' ) //大体意思这样，DataSet 就“成为”了一个真实可用的 Staff 对象，它有和 AStaff 一样的姓名、出生日期等等属性（DataSet['姓名']）。
查询是查询类，查询返回一个视图，或记录集什么的，与员工类并无任何关系。点击某条记录时，从数据库主键创建员工对象，显示员工对象信息
个人之浅见，我是这样想的，并在尽量实践，不知各路英雄有何看法？
可能我还是没能完全了解你的意思,所以我对你的方法作两种分析:1.你是否是"模拟"了一个"管理器类"?也就是由它来管理具体"记录对象"建立或销毁等行为,也就是依然生成一个对象,只是在真正使用时才生成它(前提是类的所有参数可从数据库或已知环境中得到),但这解决的只是一个动态分配问题,而此问题实际上完全可以用"懒对象"来解决(也就是用一个"代理类"来动态维护"具体类"的生命期).
它所存在的问题是: 如果我同时操作的记录量很多时,此没依然很浪费(没有解决我的问题)2.还是你只是用一个"代理对象"来模拟对所有的"记录对象"的操作虚拟操作(实际上并没有记录对象),但如果这样,我不是无没在这些"对象"中建立与其它对象之间的关联了吗?(特别是动态的关联),因为我不能在这些"对象"中保存非数据库中存在的数据(如指针等),更不可能触发一个事件给别人了!哦,对了,我先声明一下,你和rustle我一定会给分的!谢谢,请继续...
实现oop思想，我经常在java版晃，发现里面谈论java如何实现oop和UML的经典帖子很多，相信能够对楼主有很多启发，另外在程序员杂志去年的合定本中有一篇J2EE与UML的实战文章，非常精彩，内容涵盖分析，建模，设计，实现等阶段，讲授的很详实，很具体，如果能够与delphi有所参照，相信定会对楼主问题的解决有所帮助。另外:楼主所言
1。"不知大家有否注意到，如果完全使用面向对象形式对数据库系统进行构造，则在使用时会产生大量的对象实例，因为“一类一表”结构所对应的应该是“一记录一对象实例”，即便使用“懒对象”，如果同时操作的记录一多，其实例数量也会相当惊人，而且用此方法又如何对检索后的数据进一步检索呢（难道非得放着SQL不用，而用手工检索吗？）"实例对象确实很多，但真的很浪费资源吗，我在学习c++时有些参考书说，类的方法对所有对象来说是共享统一代码区域（方法表 Method Table），实际上程序只是存放实例的属性值和其地址，当我们调用某一对象的方法时实际上仅仅是传了一个this指针给该方法，以指示其对某一确定对象进行操作，如果我们参照delphi，这个类最好的父类不正是DataSet吗?他一般是表的在程序中的影射，他的方法不正好对应Method Table，记录的游标不正好对应各个对象地址，至于记录的字段值当然就是对应对象属性值了。比如在java的很多用来代表某个实体的java bean都是继承自RecordSet的,以上拙见还请指教，
还有一个关系,就是一记录一对象后,如果你要从中查找一个记录,那你就不得不使用完全手工的查找方法,但如果你使用TQuery或ADO,那你就可以使用SQL了.我现在头痛的是"组的继承关系",因为组可以有子组(这一迭代是无限的),所以我如何才能用最合理的方法得到一个组所包含的所有资源(也就是组和其所有子组的资源集合),如果我不使用对象型记录,我如何去实现这一关系呢?(我现在是用动态关联的方法来实现,但这不是面向对象的方法)
“使用对象会有一系列浪费”，怎么还是那样"火",其实我真正目的是希望楼主能从JAVA中有所借鉴和启发。
而且我相信楼主的E文不算差吧，我一直觉得在java的UML建模过程中
同样也会遇到如楼主所说的问题，另外你的核心问题是不是如何建立数据库
表记录与UML建模中的对象的合理高效的影射？我也在看，希望共同学习!
还有,我看得是<UML和模式应用>(Craig Larman著),此书就是基于java平台的,虽然我没用过java,但感觉java好象并没有封装类似于DataSet的类,因为书中的模型给出了完整的数据库建模(包抱事务的实现过程),所我我认为用java和用delphi必然有不同,应该是平台设计者有不同中的思维模式,但我不清楚delphi的设计者是希望给我们一种什么样的数据库开发模式?从我个人角度看,delphi的DataSet等VCL己经很好地封装了对数据库开发框架(包括事务),所以实际上我是在寻找一种符合delphi思想的数据库开始模式(而不是java).它是怎样的?你给我的资我正在看,先谢谢了!
过，你看看它的用法和属性几乎和adoquery一样
因为现在看来,无论是delphi还是java或是.net开发框架,很多时候我们使用的并不是类,而是它们的框架(就象VCL).我开始怀疑,我们是不是根不就不应该使用"面向对象"来建模,而是应该用"面向框架"建模(当然我也知道它是基于面向对象的)?如果是就样,那前面的所有的矛盾就都能解释了,下一步是就学习如何进行面向框架的建模了...plq多谢了,此贴拖得时间太长了,这两天内我会把它结了.因为我E文不好,所以你资料我看得比较慢,如果有什么好的想法,请和我多多联系:[email protected].
记录是类，
表是类的集合，
应该是这样。
但是 一般做数据库也没有必要
弄的太清楚了。
呵呵，
但OOP做数据库 必须面队的问题是OR MAPPING
偶认为。
偶现在还没有什么好办法。
而且他们封装的也不错，至少从表象来看他们OOP(当然实现我就不怎么了解了)，
说真的关于delphiUML建模的例子好象很少。不过据说在D7里有一个附带的UML建模工具，不懂是不是真的，如果是这样的话
肯定有例子，我找找看!
有必要吗？
现有数据库系统多是关系数据库，如果“完全使用面向对象形式对数据库系统进行构造”，不就相当于做一个面向对象的数据库系统了？
所有模型直接变为code 是不现实的
同意一类多表或一表多类
国外早有成熟的理论及方案。理论看这里：
1.Encapsulating Database Access
http://www.agiledata.org/essays/implementationStrategies.html2.The Fundamentals of Mapping Objects to Relational Databases
http://www.agiledata.org/essays/mappingObjects.html3.The Design of a Robust Persistence Layer for Relational Databases
http://objects.nease.net/persistenceLayer_ch.pdf（中文版）delphi下成熟的方案首推由BoldSoft开发，后被Borland收购的bold for delphi。
其它的还有InstantObject,ObjectSight, tiOPF等。大家还是站在巨人的肩上吧。