B
barton
Unregistered / Unconfirmed
GUEST, unregistred user!
哦？那你的修改表结构意味着什么？不是添加字段或者删除字段吗？自打我用数据库以来，
我一直认为DDL和DML应该应用在不同的场合。运行是维护数据库结构我认为不可思议的事。
我一直认为DDL和DML应该应用在不同的场合。运行是维护数据库结构我认为不可思议的事。
您正在使用一款已经过时的浏览器！部分功能不能正常使用。
请尝试升级或使用 其他浏览器。
请尝试升级或使用 其他浏览器。
W
wisenow
Unregistered / Unconfirmed
GUEST, unregistred user!
偶现在作CAD二次开发
起初当我“理解”数据库怎样面向对象时，偶却开始了图形方面的编程，刚好就把原来的思想整理一下用到了二次开发里面了，现在小有成效，呵呵，还不错。
把要做的图形定义成一个类，输入需要的参数后，就可以绘制了，这是最简单的应用了。当然图形的参数要从窗口来的，这样如果用户看着界面别扭，我可以只改界面就可以了，也不用复制粘贴什么的。
涉及到一个灵活性，要实现非常灵活，如果封装过多的方法是不现实的，我的想法就是给外面提供一个“最底层”的操作，比如提供一个返回TQuery控件的东东，这样就可以在类的外面灵活的编程了，如果需要的话：）
起初当我“理解”数据库怎样面向对象时，偶却开始了图形方面的编程，刚好就把原来的思想整理一下用到了二次开发里面了，现在小有成效，呵呵，还不错。
把要做的图形定义成一个类，输入需要的参数后，就可以绘制了，这是最简单的应用了。当然图形的参数要从窗口来的，这样如果用户看着界面别扭，我可以只改界面就可以了，也不用复制粘贴什么的。
涉及到一个灵活性，要实现非常灵活，如果封装过多的方法是不现实的，我的想法就是给外面提供一个“最底层”的操作，比如提供一个返回TQuery控件的东东，这样就可以在类的外面灵活的编程了，如果需要的话：）
Y
yyanghhong
Unregistered / Unconfirmed
GUEST, unregistred user!
to barton,
减少对象间的耦合是类设计的问题, 和mapping有什么关系. 我觉得很多人对or mapping的
最大误区就是想把关系数据库中表和表之间的外键关系用对象之间的耦合来映射,这两者看起
来类似, 但有很大不同, 表关系重点考虑的是数据的存储, 对象关系重点考虑的是业务对象
的交互.花心思在表关系和对象关系的映射, 容易走火入魔
to delp,
http://bdn.borland.com/article/0,1410,22646,00.html
减少对象间的耦合是类设计的问题, 和mapping有什么关系. 我觉得很多人对or mapping的
最大误区就是想把关系数据库中表和表之间的外键关系用对象之间的耦合来映射,这两者看起
来类似, 但有很大不同, 表关系重点考虑的是数据的存储, 对象关系重点考虑的是业务对象
的交互.花心思在表关系和对象关系的映射, 容易走火入魔
to delp,
http://bdn.borland.com/article/0,1410,22646,00.html
Y
yyanghhong
Unregistered / Unconfirmed
GUEST, unregistred user!
我说的修改表结构是指在开发期间由于需求或设计的更改而导致的数据库结构的更改,
DDL, DML是具体实施方法.他们的冲突和更改设计有什么关系.
另外我说的把数据放到对象是把ado或dbexpress得来的数据缓存又复制了一次, 造成浪费.
和数据库压力是两回事
DDL, DML是具体实施方法.他们的冲突和更改设计有什么关系.
另外我说的把数据放到对象是把ado或dbexpress得来的数据缓存又复制了一次, 造成浪费.
和数据库压力是两回事
X
xiangya
Unregistered / Unconfirmed
GUEST, unregistred user!
非常高兴,看到众多兄弟有此兴趣.
所以,我也在此发表一个个人看法,主要在两点:对象和数据库,MVC.
首先使用对象是个非常之好的技术,同时对象技术倡导的是一种分析方法,btw,c语言也可以
实现对象,原因即在于此.
但是,数据库却不是对象的,至少现在打天下的关系数据库不是.即使有些厂商提供一些
对象功能,但是不会有太大的用处.因为,本质上说现在我们需要对象数据库.而对象数据库
本身发展不是很好.但是还是有些.其中有些也不错.我不想在此长篇大论对象和数据库等等.
好了,这个时候,我们需要对象-关系数据库映射了.
Delphi的DB系列,就是一个映射,只不过是它直接处理的对象集合,而不是一个对象.
但是不管怎么说,它本身就是MVC方式的.
好了,来到MVC,模型 视图 控制,MV都好理解和实现,控制怎么办?凉拌.
控制有很多种,"我说的是模型和视图之间的控制?:"
不要试着去修改和改善Delphi中DB方式的MVC.除非你今年刚初一,因为这样,你才有时间和精力去做太多的事情.
没有办法吗?有Depo,或者tiFramework,两个都挺好.对你自己要实现MVC很有帮助.我更偏好
Depo一些,其中一个原因就是它的代码现在还不是很多,所以思路理起来容易一些.
我建议你使用QuantumGrid4,然后使用Depo,中间通过cxcustomDatasouce控制,做一个MVC
的程序出来.同时我也希望大家能把Depo搞起来
如果你不懂MVC,上面的Depo和EQGRid4的结合就是一个好例子.
如果你懂MVC,上面的Depo和EQGRid4的结合就是最好的例子.
其他的东西,我们再说吧.
所以,我也在此发表一个个人看法,主要在两点:对象和数据库,MVC.
首先使用对象是个非常之好的技术,同时对象技术倡导的是一种分析方法,btw,c语言也可以
实现对象,原因即在于此.
但是,数据库却不是对象的,至少现在打天下的关系数据库不是.即使有些厂商提供一些
对象功能,但是不会有太大的用处.因为,本质上说现在我们需要对象数据库.而对象数据库
本身发展不是很好.但是还是有些.其中有些也不错.我不想在此长篇大论对象和数据库等等.
好了,这个时候,我们需要对象-关系数据库映射了.
Delphi的DB系列,就是一个映射,只不过是它直接处理的对象集合,而不是一个对象.
但是不管怎么说,它本身就是MVC方式的.
好了,来到MVC,模型 视图 控制,MV都好理解和实现,控制怎么办?凉拌.
控制有很多种,"我说的是模型和视图之间的控制?:"
不要试着去修改和改善Delphi中DB方式的MVC.除非你今年刚初一,因为这样,你才有时间和精力去做太多的事情.
没有办法吗?有Depo,或者tiFramework,两个都挺好.对你自己要实现MVC很有帮助.我更偏好
Depo一些,其中一个原因就是它的代码现在还不是很多,所以思路理起来容易一些.
我建议你使用QuantumGrid4,然后使用Depo,中间通过cxcustomDatasouce控制,做一个MVC
的程序出来.同时我也希望大家能把Depo搞起来
如果你不懂MVC,上面的Depo和EQGRid4的结合就是一个好例子.
如果你懂MVC,上面的Depo和EQGRid4的结合就是最好的例子.
其他的东西,我们再说吧.
B
barton
Unregistered / Unconfirmed
GUEST, unregistred user!
絮絮叼叼半天到底想表达什么？数据感知不可替代？Dataset不可替代？莫名其妙。
B
barton
Unregistered / Unconfirmed
GUEST, unregistred user!
to yyanghhong:正是表关系不能映射为对象关系才需要mapping。还是zzsczz说的那句：多
维的业务关系与平面的数据库关系天然不兼容。Dataset的确也是一种映射，但依然是平面
的。
维的业务关系与平面的数据库关系天然不兼容。Dataset的确也是一种映射，但依然是平面
的。
B
barton
Unregistered / Unconfirmed
GUEST, unregistred user!
UI/Biz/DB三层分为三个封闭的系统，层间耦合尽可能少，层内可以适当耦合以提高效率。
mapping只解决了Biz和DB间的很少一部分，根本的目的还是要传达到UI层的。
mapping只解决了Biz和DB间的很少一部分，根本的目的还是要传达到UI层的。
Y
yyanghhong
Unregistered / Unconfirmed
GUEST, unregistred user!
UI/Biz/DB不完整, 标准的是数据层/持久层/业务层/表示层, OR Mapping实现数据层/持久层开发管理的自动化, 业务层只从持久层获得数据, 业务对象的关系超出了OR Mapping的探讨问题,
J
jming
Unregistered / Unconfirmed
GUEST, unregistred user!
你的问题我看了，不过以我的经验来看，绝对的代码重用是一个骗局。这一点是很多大师级的人们所认同的。我这三年写了十几个项目，没有那两个可以谈得上有共同特征的，最多就是几个能够帮我把界面搞得漂亮一点的控件而已。
如果非要做到代码重用，界面与数据分离，那你只好去生产某一种中间件了，就好像生产汽车一样，你只生产轮胎，你的重用性和分离性就很高，如果你生产整车，你就需要考虑各种各样的问题。不同型号的车就需要不同规格的轮胎，不同规格的轮胎，就需要不同的模具。既然你都造了两个模具了，还有什么重用性可谈？
我现在只想做到模块化，就是一个项目可以让几个不相干的人独自去完成，将模块与模块之间的耦合度降到最低，并且最大化的提升系统的鲁棒性。
如果非要做到代码重用，界面与数据分离，那你只好去生产某一种中间件了，就好像生产汽车一样，你只生产轮胎，你的重用性和分离性就很高，如果你生产整车，你就需要考虑各种各样的问题。不同型号的车就需要不同规格的轮胎，不同规格的轮胎，就需要不同的模具。既然你都造了两个模具了，还有什么重用性可谈？
我现在只想做到模块化，就是一个项目可以让几个不相干的人独自去完成，将模块与模块之间的耦合度降到最低，并且最大化的提升系统的鲁棒性。
B
barton
Unregistered / Unconfirmed
GUEST, unregistred user!
没有“绝对的代码重用”这一说。代码重用仅仅是oo的效果之一并不是追求的唯一境界。中
国为什么连CMM2都没有几家公司通过，我想就是...哎，还是不说的好。
国为什么连CMM2都没有几家公司通过，我想就是...哎，还是不说的好。
人
人在昆明
Unregistered / Unconfirmed
GUEST, unregistred user!
www.playicq.com 的
delphi 的 持久性对象框架
请下载研究，好东西！
delphi 的 持久性对象框架
请下载研究，好东西！
活
活化石
Unregistered / Unconfirmed
GUEST, unregistred user!
谢谢人在昆明,酒醒之后,早上在PLAY一逛发现了,呵呵
Y
yyanghhong
Unregistered / Unconfirmed
GUEST, unregistred user!
to 人在昆明,
我www.playicq.com 帐号没了, 你可不可以发一份给我, yyanghhong@yahoo.com, 谢谢,
我www.playicq.com 帐号没了, 你可不可以发一份给我, yyanghhong@yahoo.com, 谢谢,
P
pdw536129
Unregistered / Unconfirmed
GUEST, unregistred user!
moonbird888
想要人铁源代码来研究一下哦！
楼上的人全是高手，在此学习让俺受益非浅
想要人铁源代码来研究一下哦！
楼上的人全是高手，在此学习让俺受益非浅
Y
yangying_2000
Unregistered / Unconfirmed
GUEST, unregistred user!
to barton:
我认为数据感知控件和TDATSET的抽象结合正是VCL中的最大亮点之一,否则VCL在数据库编写方面就会象MFC一样了.
在面向对象设计方面,我想可以考虑这样的思路:
表结构就是类,而表中的记录就是对象,存储过程是方法,触发器类似事件,我想这样一比较大家就会发现数据库表的设计也就是类设计,所以才会出现JAVA的JDO(JAVA DATA OBJECT)概念.
代码重用主要体现在通用类的抽象,这里的通用类指的是业务逻辑,比如用户/客户/权限/模块/报表等,以上列举的类都是每个应用系统都必须要实现的部分,在基础上都是一样的,所以完全可以抽象出来,那么在绝大多数系统中都可以使用,但是抽象时候只能抽象到与具体应用系统无关的部分.
举个例子,对于权限设计,我一般是先定义一个抽象类权限,然后再继承出模块权限/报表权限/资源权限等,所以对应到数据库就是权限表,然后是模块权限表/报表权限表/资源权限表,以上子类的主键和父类的主键是关联外键对应于数据库,这就是类化的数据库设计,便于扩充,比如你要想扩充一种权限控制,增加一个表就可以了,也就是增加一个类.
而客户和用户的抽象可以这么做,先定义一个自然人类和一个社会实体类,客户指的是商业客户,即可能是人也可能是社会实体,因此客户会有一个客户ID,另外再加两个外键对应于自然人和社会实体,在触发器里定义互斥限制,在客户是自然人时就不能是社会实体,是社会实体时就不能是自然人.而自然人这个类又可以用到用户类里,因为用户是相对于应用系统的使用者而言的,也就是一定对应于一个自然人,这样在用户里定义自然人只需要关联到自然人类,这就是重用,包括对自然人的编辑也可以直接重用,也就是代码重用.
上面讲的是类抽象继承,没有牵涉到接口,接口的设计也可以体现在数据库中,比较复杂就不赘述了.
我认为数据感知控件和TDATSET的抽象结合正是VCL中的最大亮点之一,否则VCL在数据库编写方面就会象MFC一样了.
在面向对象设计方面,我想可以考虑这样的思路:
表结构就是类,而表中的记录就是对象,存储过程是方法,触发器类似事件,我想这样一比较大家就会发现数据库表的设计也就是类设计,所以才会出现JAVA的JDO(JAVA DATA OBJECT)概念.
代码重用主要体现在通用类的抽象,这里的通用类指的是业务逻辑,比如用户/客户/权限/模块/报表等,以上列举的类都是每个应用系统都必须要实现的部分,在基础上都是一样的,所以完全可以抽象出来,那么在绝大多数系统中都可以使用,但是抽象时候只能抽象到与具体应用系统无关的部分.
举个例子,对于权限设计,我一般是先定义一个抽象类权限,然后再继承出模块权限/报表权限/资源权限等,所以对应到数据库就是权限表,然后是模块权限表/报表权限表/资源权限表,以上子类的主键和父类的主键是关联外键对应于数据库,这就是类化的数据库设计,便于扩充,比如你要想扩充一种权限控制,增加一个表就可以了,也就是增加一个类.
而客户和用户的抽象可以这么做,先定义一个自然人类和一个社会实体类,客户指的是商业客户,即可能是人也可能是社会实体,因此客户会有一个客户ID,另外再加两个外键对应于自然人和社会实体,在触发器里定义互斥限制,在客户是自然人时就不能是社会实体,是社会实体时就不能是自然人.而自然人这个类又可以用到用户类里,因为用户是相对于应用系统的使用者而言的,也就是一定对应于一个自然人,这样在用户里定义自然人只需要关联到自然人类,这就是重用,包括对自然人的编辑也可以直接重用,也就是代码重用.
上面讲的是类抽象继承,没有牵涉到接口,接口的设计也可以体现在数据库中,比较复杂就不赘述了.
B
barton
Unregistered / Unconfirmed
GUEST, unregistred user!
完全同意你在数据库设计方面的安排，但与数据集及数据感知控件有什么关系你并没有说明
呀。因为数据集基本上是平面数据库的映象，必须符合数据库设计的一个原则：尽可能地减
少冗余；而类设计的原则则是尽可能地减少对象间的耦合。这点完全注定了数据库中的表格
不可能和运行时的类重叠。再一点，即使是能够重叠也不可能表达同样的概念。
按你的贴子中的客户、自然人和社会集团实例我们再作进一步的分析(我的售楼系统中正巧
用到)。
客户是抽象的，自然人和集团是具体的。在数据库设计时需要三个表：客户、自然人和集团
人，因为三者具有不同的属性。设计类的时候也需要三个，只是自然人和集团人均继承自客
户。可是在生成对象的时候，只有两途中对象：自然人和集团人，不可能有抽象的客户。
好。你统一用两个数据集来表达：一个是自然人数据集，一个是集团人数据集。那么我问你，
如何将这两个数据集统一在一个平面上？我同意数据集可以表达大部分模型，但很多的时候
表达不了也是现实。数据集没有提供一个用户设计的空间来保证用户按非平面模型时保证继
续与数据感知控件的协作。象dbgrid这样的控件完全是以牺牲数据库性能的代价为基础的。
这个问题可以参考我1999年与huizhang之间的讨论(不知道大富翁还能不能找见，那时候我
只有两年有Delphi应用史)。
呀。因为数据集基本上是平面数据库的映象，必须符合数据库设计的一个原则：尽可能地减
少冗余；而类设计的原则则是尽可能地减少对象间的耦合。这点完全注定了数据库中的表格
不可能和运行时的类重叠。再一点，即使是能够重叠也不可能表达同样的概念。
按你的贴子中的客户、自然人和社会集团实例我们再作进一步的分析(我的售楼系统中正巧
用到)。
客户是抽象的，自然人和集团是具体的。在数据库设计时需要三个表：客户、自然人和集团
人，因为三者具有不同的属性。设计类的时候也需要三个，只是自然人和集团人均继承自客
户。可是在生成对象的时候，只有两途中对象：自然人和集团人，不可能有抽象的客户。
好。你统一用两个数据集来表达：一个是自然人数据集，一个是集团人数据集。那么我问你，
如何将这两个数据集统一在一个平面上？我同意数据集可以表达大部分模型，但很多的时候
表达不了也是现实。数据集没有提供一个用户设计的空间来保证用户按非平面模型时保证继
续与数据感知控件的协作。象dbgrid这样的控件完全是以牺牲数据库性能的代价为基础的。
这个问题可以参考我1999年与huizhang之间的讨论(不知道大富翁还能不能找见，那时候我
只有两年有Delphi应用史)。
活
活化石
Unregistered / Unconfirmed
GUEST, unregistred user!
这周太忙,下周结贴.此贴收益非小,大富翁都是活雷锋
程
程序小鱼
Unregistered / Unconfirmed
GUEST, unregistred user!
这个问题说起来不是一句话
I
ifcansee
Unregistered / Unconfirmed
GUEST, unregistred user!
ding