讨论OOA,OOD程序框架的实现(可以加分) ( 积分: 200 )

刚刚接触OOA和OOD,有些问题麻烦各位指点一下:
1.实体类的应用
实体类到了实现阶段会衍生出三个类:界面类,业务逻辑类,数据访问类.这三个类和实体类之间的关系应该是什么样的?是要在实现中应用实体类,还是让它转化为业务逻辑类?
例如:实体类TOrder,界面类TOrderUI,业务逻辑类TOrderBusiness,数据访问类TOrderData
方案1:保留实体类.由TOrderUI, TOrderBusiness, TOrderData引用实体类.TOrderBusiness可以提供一个TOrder的集合,用于提供多条数据的显示.这种情况下,因为TOrder基本不包含业务逻辑,所以基本上相当于一个Record,仅仅是属性的容器而已.
方案2:把TOrder转化为TOrderBusiness.TOrderBusiness包含TOrder的全部属性,并且封装业务逻辑,还要包括一些类方法(class method)如Query(TCondition;
TOrderBy)用以返回一个包含TOrderBusiness对象的集合.
我更倾向于方案2.请问哪种方案更好一些?还有其他的方案吗?
2.数据访问层的实现
是每个实体类对应一个数据访问类,还是使用同一的数据访问实现?
前者的优点是开发简单,缺点是重复较多,重用性差.
后者重用性好,但是需要使用配制文件来提供对象和表的映射关系.而且好像很难完成把数据置入相应对象的操作,恐怕只能交给业务曾实现.
3.读取数据并置入对象的问题
将表数据转化为对象的这一步到底应该在哪一层实现?
感觉好像应该在数据访问层实现,这样业务逻辑层就只涉及业务关系的实现而不必考虑数据的问题.这样的实现似乎比较符合第一个问题的方案1,因为按照方案2实现的话,会导致数据访问类引用(不是调用)业务逻辑类.
如果在业务逻辑类中实现的话,数据访问类应该如何返回数据呢?
4. 1:N关系的实现
1:N关系置入对象应该在哪一层实现?
如果在数据访问层实现的话,可以方便的使用表连接来解决问题,但是会导致数据访问层引用更多的业务逻辑类.
如果在业务逻辑层实现的话,感觉上更合理一些,因为毕竟是业务逻辑中存在的关系,而且还可以应用Lazy Initialization.但是可能效率会下降.
1:1和M:N又该如何实现置入.
5.接口的实际应用
如果我的程序不使用物理上的多层,那么定义和使用接口有什么好处?它和抽象类在使用上(不是定义上)有什么区别?
问得比较乱,请多包涵.
我刚接触OOA和OOD,这些问题可能很可笑,请不要见怪.[]
希望各位高手能多多指教,提供一下宝贵经验.

刚刚接触OOA和OOD,有些问题麻烦各位指点一下:
1.实体类的应用
实体类到了实现阶段会衍生出三个类:界面类,业务逻辑类,数据访问类.这三个类和实体类之间的关系应该是什么样的?是要在实现中应用实体类,还是让它转化为业务逻辑类?
例如:实体类TOrder,界面类TOrderUI,业务逻辑类TOrderBusiness,数据访问类TOrderData
方案1:保留实体类.由TOrderUI, TOrderBusiness, TOrderData引用实体类.TOrderBusiness可以提供一个TOrder的集合,用于提供多条数据的显示.这种情况下,因为TOrder基本不包含业务逻辑,所以基本上相当于一个Record,仅仅是属性的容器而已.
方案2:把TOrder转化为TOrderBusiness.TOrderBusiness包含TOrder的全部属性,并且封装业务逻辑,还要包括一些类方法(class method)如Query(TCondition;
TOrderBy)用以返回一个包含TOrderBusiness对象的集合.
我更倾向于方案2.请问哪种方案更好一些?还有其他的方案吗?
2.数据访问层的实现
是每个实体类对应一个数据访问类,还是使用同一的数据访问实现?
前者的优点是开发简单,缺点是重复较多,重用性差.
后者重用性好,但是需要使用配制文件来提供对象和表的映射关系.而且好像很难完成把数据置入相应对象的操作,恐怕只能交给业务曾实现.
3.读取数据并置入对象的问题
将表数据转化为对象的这一步到底应该在哪一层实现?
感觉好像应该在数据访问层实现,这样业务逻辑层就只涉及业务关系的实现而不必考虑数据的问题.这样的实现似乎比较符合第一个问题的方案1,因为按照方案2实现的话,会导致数据访问类引用(不是调用)业务逻辑类.
如果在业务逻辑类中实现的话,数据访问类应该如何返回数据呢?
4. 1:N关系的实现
1:N关系置入对象应该在哪一层实现?
如果在数据访问层实现的话,可以方便的使用表连接来解决问题,但是会导致数据访问层引用更多的业务逻辑类.
如果在业务逻辑层实现的话,感觉上更合理一些,因为毕竟是业务逻辑中存在的关系,而且还可以应用Lazy Initialization.但是可能效率会下降.
1:1和M:N又该如何实现置入.
5.接口的实际应用
如果我的程序不使用物理上的多层,那么定义和使用接口有什么好处?它和抽象类在使用上(不是定义上)有什么区别?
问得比较乱,请多包涵.
我刚接触OOA和OOD,这些问题可能很可笑,请不要见怪.[]
希望各位高手能多多指教,提供一下宝贵经验.

对于数据库的设计，我也想学习学习，最好是“设计模式”

学习，一下。

1、似向于第二种方案；
2、要将业务逻辑和界面和数据访问分离，要做成通用的访问，但是这样似乎有点复杂，工作量大，逻辑考虑太多；
3、数据访问层实现，同第二点一样，已经做到分离了；
4、不太懂
5、接口是为了扩展及通用模块的扩展，如果在D里也可以用抽象类实现，但是为了程序语言的扩展，最好用接口来进行定义
个人愚见，好像上面还有提到o-r mapping的问题，想过一段时间，但终实现复杂，所以没用了

Delphi 下我还没看到过一套实用的ORM工具

来自：QSmile, 时间：2005-6-28 15:34:34, ID：3116895
Delphi 下我还没看到过一套实用的ORM工具
以前有过BOLD,现在是ECO(Enterprise Core Object).
我自己也仿照Hibernate实现过一个只是处理1:N的时候有点问题（N的加载），多对多没有实现。实现了缓存。

还实现了自动回收

据说 borland 的 ecoii 暴猛，可惜一直没有时间去钻 ...
＝^0^＝

谢谢大家
期待更多的讨论，最好是意见和建议

to LSUper:
有没有ECOII的资料。

我也想学习一下

哦，这样呀。
看来我的功力还是不够 。
哪里有 ecoii 的资料？

1。业务是谁的业务，自然是实体的业务，实体类不应该是一个简单的数据容器（RECORD），而是一个能干活的对象。所以泛泛而谈的话，实体类本身应该是业务类，选方案二。
2。是每个实体类对应一个数据访问类
3。业务层能看到存储层，而存储层不能看到业务层。业务层需要把从存储层传上来的某种格式的数据变成实体类。
4。看到N：M就有点头痛，不发表意见：）
5。可以认为，纯抽象类=接口。 我更倾向与用接口编程。
比如：
TOrderData继承自一个TAbstractData抽象类(负责装数据，比如内部有一个某中形式的DataSet)，
而它可以实现Idbms接口（select,delete,update,insert）
这是，在TOrderBusiness中就可以直接用借口来访问TOrderData对象。

话说过来，OO和RDBMS还是有些别扭的，没有最好，只有适合
给你个老帖子
http://www.delphibbs.com/delphibbs/dispq.asp?LID=946305
其中谈的《PEAA》（Partern of Enterprice Appication Architecture）网上能找到E文的CHM版，中文版我也刚看到。
也许，刘艺的《设计模式》你还可以一看的。

罗嗦完了

如果能对程序中的业务逻辑抽取出其模式，
就能简化实现

我自己在摸索中的面向数据思想认为，业务逻辑、业务规则也是数据，它们是用来描述
业务数据的数据，也就是所谓的元数据。
我们在编程中最常用最简易的元数据就是配置文件，其实它可以是任何形式：INI、XML、
注册表、数据库表。我们开发中经常会设计代码表，这也是元数据，也是业务逻辑的一个
层面(简单的比如会计科目：代码对应科目)，所以，我的做法是数据访问层采用自己定义
的通用数据访问框架来实现。
关于用户界面层，我一直认为抽象类TDataSet是Borland的一个杰出的设计，不要将它简
单地看成是数据库表的存取接口，如果你参透了DataSnap(MIDAS)的精髓，我们完全可以
把TDataSet看成是一种类似于TList的动态数据类型。这种数据类型，可以很简单地从
文件、数据库表 物理存储层读取数据，也可以更简单地通过数据感知机制与用户界面层
交互数据。所以我的做法是：
数据感知 -- 业务对象(TDataSet,TClientDataSet) -- 数据访问(Query) -- 库连接
关于业务规则如何数据化，用lich的一句“对程序中的业务逻辑抽取出其模式”来说明，
比如：代码表、模板、流程、表单 等等，它们都是业务规则的各种经典设计模式，都能
被数据库表定义。

谢谢各位的答复！
感觉挺恐怖的。
如果连业务逻辑也能提取的话，那岂不是一个程序跑遍天下了？太爽了！
想都没想过还可以这样。
不过实现起来还是相当复杂的吧！工作量肯定不会小，不过倒是可以一劳永逸[]
最近在看http://www.agiledata.org/，上面有不少好的思路。
给分了。