面向对象可行吗？

[ShallowShrimp]

举个例子，某企业从客户处接到订单后，会对订单进行录入，编辑，修改(如交期)等操作，首先订单信息在后台分别由主／从表保存，主表保存订单主信息，如订单号，客户，下期日期等，明细表记录订单明细，如品种，数量，重量，交期等．

用一般的程序设计方法，我们可以写SQL语句查出多个订单主从信息，得到数据集之后很方便地用控件显示出来，用户可以对主从信息进行集体修改，然后一起保存，未保存之前也可以全部取消．

用面向对象的方法，是否对每个订单创建一个对象？如果这个订单包括主/从两层信息，对象的数据结构应如何表示？订单对象如何提供方法修改内部数据？是否要自己写界面而不能使用现有的数据集控件了？是否只能对订单进行单个操作？对订单的修改能否不立即保存至后台数据库？如果要实现能满足一般程序设计方法的功能，这个订单对象应如何地设计？

请大家提出自己想法，也请各位高手不吝赐教！

[dlysw]

各位谈谈对面向对象的认识吧

[Schlemiel]

多简单啊，订单对象包含明细单对象的一个引用嘛。用一个O/R mapping工具，对象缓冲、lazy loading之类的功能全有了。这种典型的OLTP，用面向对象方法最合适。

[chenkk1978]

对每个订单创建一个对象??好像不好吧
建立一个订单的基类，继承，引用比较好一些

[Schlemiel]

拜托，对象和类的概念分清楚再开口好不好。

[zhuma]

面向对象和数据库
麻烦亚

[ShallowShrimp]

To Schlemiel(维特根斯坦的扇子),
非常感谢你的回复，我的问题已经得到了答案：

用面向对象的方法，是否对每个订单创建一个对象？
是

如果这个订单包括主/从两层信息，对象的数据结构应如何表示？
订单对象应该分解为两个对象，主订单对象与明细订单对象

订单对象如何提供方法修改内部数据？
两上对象分别实现方法

是否要自己写界面而不能使用现有的数据集控件了？
要自己写界面

是否只能对订单进行单个操作？
不是

对订单的修改能否不立即保存至后台数据库？
可以

如果要实现能满足一般程序设计方法的功能，这个订单对象应如何地设计？
同样可以实现，但复杂了很多。

我也曾经自己在程序中写过数据表记录至对象转换的过程，那是因为每个对象都要参与复杂的计算，那样写出来的程序确实灵活可读很多。不过对于象订单管理这样简单的操作如果也采用这种技术的话，显然是非常低效的，不可否认面向对象技术能够构造出高度灵活（易移植、易变更等）的程序，但是也不是十分必要的，充分利用开发工具提供的控件就可以在一个钟头之内把订单管理功能写完成，为什么偏偏要用面向对象花两天来完成，得到的结果都是一样的，效率反而低了很多，开发成本也大大增加。

[zhuma]

To Schlemiel(维特根斯坦的扇子)：

明白了
谢谢
呵呵

[ShallowShrimp]

To Schlemiel(维特根斯坦的扇子)
我看了一些关于O/R mapping的文章，感觉别人的评价也不是很高
如：http://acm2.ustc.edu.cn/~roger/techclip/archives/000045.html

我就拿VB、Delphi举例，此二工具都提供了相当丰富的“数据库操作控件”，如果按你那种O/R mapping写法，显然是不能很好地利用“数据库操作控件”，就算可以也是又需要将对象转回数据集，非常麻烦。
你是学JAVA的，不知道JAVA中如何实现数据库程序，如果要对对象进行操作（如数据输入、修改等），那岂不是要自己为每个对象写界面？这样的方法开发效率不是很高吧？

[Schlemiel]

先说说你推荐的那篇帖子吧。那里有个人说：
“问题是, 现在使用o-r mapping的环境基本都是这种方式, 原因是要映射到数据库表的那些类基本都是映射工具自动生成, 所以不大可能在其上添加操作”

这哥们是只知其一不知其二。他用的大概就是像castor那样的O/R mapping，先有数据库schema，再从schema导出类，结果添加操作不方便。既然你是做以业务为核心的OLTP，为什么不换个角度来想想，先定义类（包括数据和操作），再根据类定义生成数据库schema？实际上，Java社群真正使用的O/R mapping方案无一例外都是这样的做法。常见的通用O/R mapping解决方案包括Hibernate和JDO等，你如果有兴趣可以关注一下。

所谓“数据库操作控件”，说实话我早已不太知道它存在的价值是什么——至少在OLTP类业务中。对于OLTP业务，我首先想到的是实体对象和业务流，而不是数据库。既然我要实现的是一组业务，数据库跟我有什么关系呢？也许这是个方法学的问题，不那么容易解释清楚，先试着解决一下你的问题，看看能不能对你有所帮助吧。如果我的理解有什么偏差，请马上提出来。

数据库操作控件的好处大概是可以自动化数据库的连接、查询与更新操作吧？但是，当你使用一个典型的O/R mapping方案（例如JDO）时，你根本就不会知道数据库的存在。你通过JDO的API load一个对象，操作它，再调用JDO的update方法对它序列化，一切仅此而已。在展示层上，我根本不必考虑数据库的问题。以你的问题为例，我可能会用struts的form-bean通过表单的输入生成一个“订单”对象（这个对象是一个POJO，plain-old Java object），把“明细单”对象（同样，一个POJO）的引用交给前者，然后调用JDO的save方法把前者保存起来，一切就OK了。无须关心数据库的结构，无须关心跨表查询的细节，无须关心引用完整性。当然，效率很可能降低。

你推荐的那篇帖子里，有几个人似乎在用AOP给dumb数据类加入操作，这是对AOP的一种误用。AOP解决的问题是正交分解的cross-concern，而这个问题完全没有正交分解，只不过是他们没有用好O/R mapping而已。

[zhuma]

To Schlemiel(维特根斯坦的扇子):

冒昧问一句
"维特根斯坦的扇子"典出何处
好奇而已
呵呵

[Schlemiel]

在Rod Johnson的那本书里，对于“对象核心的建模”和“数据库核心的建模”有相当精辟的阐述。一般来说，如果数据库schema的稳定性要求强于J2EE对象模型，则应该以数据库为核心来建模；反之则以对象为核心。在你的这个例子中，似乎并没有要求数据库schema的稳定性，所以我觉得先建立对象模型，再根据对象模型自动导出schema是一个理想的方案。

[Schlemiel]

to zhuma(竹马) ：
维特根斯坦是英美分析哲学的鼻祖，现代哲学的两位最重要人物之一（另一位是海德格尔，大陆人文哲学的开山）。至于扇子，其实就是“fan”，明白了吧？