仓库管理软件版1楼: 不使用数据模块，而使用域对象。
交流一下经验

2楼: 先告诉我一下为什么要使用域对象，从设计或开发的角度有什么好处或方便？
Delphi中如果只是简单的将TABLE转换为Model对象，根据就没有什么实际意义！
关键是没有“R”的支持！！JAVA这方面就很优秀了，这是其他语言的先天不足！ 如工程项目管理软件

3楼: 难道楼上的只认为面向对象属于语言特性吗？
只有JAVA才有？
JAVA因为应用领域的特性,才位居上层,所以谈不上其他语言的先天不足
面向对象是一种思想,跟实现没有关系

我也是最近才真正转向面向对象设计的
以前的习惯是写数据模块,当时那个阶段很自然的想法,但却造成了难以维护的局面,仅注释就得写一大堆,可以说以前是基于对象的设计
现在我的习惯已经转向面向对象,虽说还是新手乍练,但我已经深刻的感受到了它的好处,起码,代码就是我的注释.

4楼: 不过,为什么要用面向对象也是我想了很长时间的问题,到现在才开始隐约清楚些答案

5楼: 》》难道楼上的只认为面向对象属于语言特性吗？
》》只有JAVA才有？
难道楼上认为我说的是面向对象特性？？
什么是面向对象设计？设计了Model对象就是面向对象？！
我说的是使用域对象模型驱动的设计开发！为什么要使用域对象开发？

6楼: -----------------------------------------
在一个简单的Web应用程序里，一个域对象模型能 被用于所有的层，然而，在一些复杂的Web应用程序里面，一个单 独的视图对象模型需要被使用。域对象模型是关于业务对象，应该归 入业务逻辑层。它包含特定业务对象相关的业务数据和业务逻辑。一 个视图对象包含特定数据和行为的表示。JCatalog项目的P roductListBean提供了一个好的例子。它包含表示层 数据和逻辑细节，举例来说，与分页相关的数据和逻辑。从域对象模 型分离视图对象的缺点是数据映射必须发生在两个对象模型之间。
----------------------------------------

仓库管理软件版7楼: Delphi能实现数据关系映射吗？呵呵
你看看，能查到的一些资料都是以JAVA为例，B/S系统因为http请求是无状态协议，使用分层设计的诸多好处能起到立杆见影的效果，C/S可能不是那么明显。
再说，以Model驱动的开发首先要求 业 务 设 计必须是OO的，否则非OO的设计强求OO的代码，得不尝失！

8楼: 我觉得使用Delphi进行面对对象数据应用程序设计并不是不可能的事，只是会失去诸多

可视化编程的方便与快接，而这又是Delphi的强项。
举一个例子，如果我们将一个订单用一个类来定义，那么多个定单用什么来表示呢？
用对象数组来表示好象是一个办法，但如何与DBGrid相关联呢，又如何与报表相关联呢？
整日在学面对对象编程，但实际还是停留在数据模块这种面对过程之中，
实在令人悲哀呀！

9楼: 学习一下！[:)]

10楼: 什么是 ＇＇使用域对象＇＇,请将明白一点,希望多交流,能提高的更快!

11楼: >>Delphi能实现数据关系映射吗？
如果说做为语言的Delphi不能，那么原始意义上的Java好像也不能吧... 除了多了层虚拟
机之外，Java有何根本优势可言？只要我们愿意，完全可以为任何语言做虚拟机。不过，我
更愿意搞定语言之上的程序控制流这一层——语言是什么东西？——钢笔、圆珠笔罢了。
OR映射，我正在用Delphi来做，用起来非常爽——不过，严格的说来，这个OR中的O已经
不再是OOP中的O了。
话说回来，“域对象”这个概念我还是头回听说。好像MDA中也没有这个词吧...

>>如果我们将一个订单用一个类来定义，那么多个定单用什么来表示呢？
对于这种“集合”，我现在是用分层次的数据对象树来实现的。
另：“一个”订单只是一个订单对象而已，谈不上类。类和实例可不能弄混了:P

12楼: OO概念接触好长时间，实践不久。
什么叫数据模块？
难道因为有个DataModule就叫数据模块？
数据模块也仅仅是个称呼而已，用不用数据模块关OO什么事。
OO一词，也仅限于对事物的抽象方式不同而已
数据模块是大家已经习惯了在数据的操作上进行封装，大家的封装方式还不一定一样呢
有一天照样可以不叫数据模块，你如果以对象封装数据我觉得也可以把数据叫做域对象
名字还不错。都是结合了具体情况而言。
每一个类的设计都是有代价的（我看过了封装了很好的类，可代码量呢，执行效率呢），
每个工程OO的角度也是不同的。
一点浅见!望大家批评 如用友财务软件破解版

13楼: >>OR映射，我正在用Delphi来做，用起来非常爽——不过，严格的说来，这个OR中的O已经
不再是OOP中的O了

我不知道你的OR映射是做到什么程度？能体现对象之间的关系(1;1,1:n,n:n)吗？
或者只是将table映射为object？只不过对象的关系用String来体现？
所谓的域对象，就是Domain Object 它不完全等于实体对象
Java的优势是虚拟机，但Delphi又何必跟风呢？好钢要用到刀刃上！
程序是不是OO不是很重要，关键是能做到代码复用，业务逻辑复用可维护就足够了！
在B/S中分层设计最能够体现这一点，Web Layer<->Biz Layer<->Services Layer<->Data Access Layer 可能实际当中更提倡的是面向接口编程

仓库管理软件版14楼: 现在我们这里1:1的关系（我们称之为影子表）在具体操作的时候可能会有问题，而1:N和
N:M的关系已经搞定。我们现在利用实体之间的Relation建立更高层次的跨表对象（类似数
据库中的视图）——我想这也许就是一种最简单的Domain Object吧。目前正在考虑建立独
立（或者说部分独立）的表现层——完全基于模型的界面展示太过单一了。
关于Services Layer，在阅读了介绍Spring的文章之后，我在系统内核也建立了一套完全
透明的“任务注入”机制。
关于业务逻辑复用，我们现在面临的局面是——像SAP这样的大型系统，以他们多年的行
业积累，沉淀了无数业务逻辑，在一段时期内，我们很难在这方面和他们抗衡。但他们的表
结构以及程序代码都是公开的，如果能够从代码中抽象出业务逻辑，就能实现知识的迁移，
壮大我们自己的业务系统了。（另：在我们的框架下，根本不存在“代码复用”的问题——
一切都是逻辑！）

15楼: 能做到以上就足够了，基本上每个公司都有自己的一套架构，一套开发模式与解决方案，可以做到一定程度的代码复用与业务逻辑复用，就如以上的4层；关于业务逻辑的复用我们是通过XML配置接口实现，客户端无须修改代码就可以做到业务逻辑实现的替换(当然我是用Java,Delphi 02年后都没用过了)，扯远了偏离主题了~~~~
一句话,是否OO不重要，只要设计(代码)层次逻辑清楚，能做到可扩展、可维护、可复用，那么OK!

16楼: 怪不得中国的软件比不过别人呢!只顾眼前蝇头小利！！图快图方便

17楼: 学习了……

18楼: 占座，听课 [:D]

19楼: OOP不是一种思想吗？

20楼: 还在争论姓资还是姓社的问题，真有那么重要吗？
哎，老了，学不动了，就只会去骗点小钱了:)