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等。大家还是站在巨人的肩上吧。