探讨“数据库系统的面向对象开发” (0分)

我觉得这些方法多不好！代码量是相当的大。

等你们讨论完我的项目已经完成了。

业务流程是可变的，业务对象也是可变的。
没有一个方案能让所有的业务一劳永逸的重用。

我极为反对‘property BookType:string read GetType write SetType;’这种做法。我们应知道所开发的系统的性质，面向数据库的应用时，数据对象本身就已经是数据库中定义的表结构，我们在这里大谈特谈面向对象的数据库应用时，有谁考虑过数据库系统本身就是一个对象？我们总做一些重复的所谓封装数据的对象设计。难道大家不用数据库组件存取数据么？
在处理业务流程，企业规则时，请大家从实际的项目需求出发。如何分析出业务对象，以及整合业务流程。因为不管你的数据对象设计得多么完善通用，业务对象、业务流程、企业规则都是每个系统开发时必须重新设计的工作，因为不同的系统有不同的功能需求。请记住，功能需求是重点！我们总是在接到新的项目时，想得更多的就是如何将它设计得通用一点，大家专注一点吧，想想实际要做的事情是什么。

為什麼一定非要面向對象不可??
程序做多了,才發覺面向對象并不是什麼神仙丹,反而開始覺得有點華而不實!!
面向過程比面向對象更實用...

汗。。。。。。
严重学习！

对于面向数据库的对象开发，并不是高深的讨论话题。
我们在这里信誓旦旦的讨论数据对象，各位都知道数据对象的最终被调用规则吗？我先说说在企业应用方案中这些数据的处理，但我是以对象的方式解说。
企业中的多个部门，比如业务部、仓管部，这些部门中都有各自的运作流程，比如业务部门的业务订单、出货单，仓管部门的领料出库，收货入库等。这些是我们真正需要了解并分析出业务对象。在我介绍这个业务对象前请大家先排开想法，不要将它和软件设计中的任何控件或类相联系。
我以‘出货单’为例，出货单是只有业务部门能做的事情，但业务部门在进行‘出货单’的数据填写前必须知道，要出货的产品在仓库中的数量是否够本次出货。而产品在仓库中的数量不是业务部能及的范围，所以业务部只有联系仓库部门才能获得需要的信息。
上面描述的即是本次流程的全过程（将‘出货单’简单化的流程），我们知道这次流程的主要对象是出货单，而且涉及到产品的库存信息。
现在我开始用程序设计中的概念分解这个流程，当然是面向对象的程序设计了。
本次流程的主要对象是出货单，所以我们在设计时也将出货单设计成一个对象，即业务对象；而在本次流程中涉及到产品的库存数量，当然这也只能是库存业务对象能及的范围，这里我们默认库存业务对象已经存在，因为我在描述出货单业务对象的设计时能体会到库存业务对象是如何设计的了。出货单业务对象处理流程：
1.将产品编号传送给库存业务对象，以获取该产品在库存中的信息。至于为什么说要传送产品编号，这是由库存业务对象中提供的接口（不过是函数或过程罢）而定的，这也是为什么我们要了解企业的实际运作流程。而所谓产品在库存中的信息，当然它们都是对象，但这些对象是我前面所说的，数据库本身就是数据对象，所以它即是我们所用的DataSet.FieldByName。

打断一下。。。
写着写着下班了。若有机会接着写吧，如果有人需要的话。

同意gondsoft的观点。
不要为了面向对象而面向对象，导致过度设计。费时费力。

呵呵，一下子10条信息发到EMAIL里，可把我吓了一跳。这条贴子好久没那么热闹啦

多谢gondsoft发表这么多看法，我也发表一些愚见吧。非常同意“业务流程是可变的，业务对象也是可变的。没有一个方案能让所有的业务一劳永逸的重用”这个观点。这条贴子本身和我以前发表的东西都着重于O-R MAPPING，但我觉得实际上一切的一切，都是围绕一个主题——分层。既然一切都在变化，没有什么能够一劳永逸，那么唯一能做的就是在变化出现时把影响尽可能减到最小。

在《重构》一书(中国电力出版社，侯捷译，p61)中有这样一句话“计算机科学是这样一门科学：它相信所有问题都可以通过引入多一个间接层来解决”,虽然有点夸张，但确实有其道理。事实上有一些约定俗成的分层已经成为业界的行规了。例如表达层(presentation)与逻辑层分离。在澳洲这边的大学的本科课程，教编程基础的时候，肯定至少有一堂课是用来提醒学生：用户界面与逻辑需要分离。连数据结构这样的学科，讲师也会不厌其烦地提醒学生“打印功能不要放在运算函数里面，否则别想及格”。因为把表达代码与逻辑代码混在一起的程序是根本没有重用性可言的。

而另一个分层，也就是分离数据访问与逻辑层，就没有那么简单了。对于小型应用来讲，业务逻辑往往就体现在SQL STATEMENT里面，或者干脆作为储存过程放在数据库端了。而用程序实现一些稍微复杂的计算，也是一目了然。对于这种情况，其实根本就不需要（或暂时不需要）分离数据访问与逻辑代码。我觉得之前那么多朋友认为我们之前讨论的东西过于复杂，问题就在于此。架构方法应该是与项目规模密切相关的。以70年代GOTO满天飞的流程化方法来做企业应用固然不妥，但对小项目一下就引入中间层，进行O-R MAPPING也是浪费资源的。

正如Martin所说：“我更倾向于容忍混合domain与data source。对许多简单的应用，这两部分可能看上去非常相似，这样的话我更倾向于把它们放在一起。但一旦我组织业务逻辑的方式开始看上去显得与data source的定义不同，我会希望把它们放到不同的模块中去。”。一旦业务逻辑与data source的定义开始不同的时候（随着系统成熟，data source结构趋于稳定，也难以改变。而业务逻辑则继续不停变动），把业务逻辑与数据访问混在一起的代码就变得难以修改与重用了。我觉得只有在这时，才有进行分层，甚至用O-R MAPPING工具封装数据库访问的必要。

gondsoft兄的讨论，也正体现了这个标准。可以看出，你的项目中业务与数据库是紧密结合在一起的。这没有好或不好之分，只要它们仍然相似，就应该把它们放在一起。但是如果有朝一日它们的差别开始越来越明显了，就可以考虑把它们分开了。

关于代码量的问题，我的看法是有条件的话，核心部分应该尽量使用第三方的企业应用开发平台。（所谓条件，就是经费充足，第三方平台足够成熟）既然一直在强调重用，在这节骨眼上搞重复开发就太不合逻辑了。

那为什么还要关注这个问题？一来即使用第三方平台，如果对原理不熟悉也是云里来雾里去，例如当年的BOLD就很多人说没弄懂。二来对一些条件不成熟，又有需要做O-R MAPPING的也可以往这个方向发展。但我觉得凭自行开发的话，除非是大型项目，有专人，并且是有经验的人去做O-R MAPPING部分。否则见效不大。

这里所说的O-R MAPPING，是指一个对象对应一条记录的，带DATA MAPPER，可以对业务逻辑代码完全隐藏数据库细节的“对象-关系映射”机制。目前在应用的例子有JAVA的JDO，和DELPHI的BOLD。有兴趣可以去看看相关的文档

to kidneyball,
能否解释一下“业务逻辑与data source的定义开始不同”是什么意思，最好举个例子来说明一下怎样从原来的“一致”演变成后来的“不同”？

>>kidneyball
‘业务与数据库是紧密结合’，你应该明白这句话的道理。在数据库应用中，我们面向的对象是什么？不就是数据库吗！现在我们需要做的就是将这些数据库对象和实际业务流程进行整合，所谓的整合就是实现业务流程（即各个业务对象）中需要处理的数据对象，以实现业务逻辑。
你说‘有朝一日它们的差别开始越来越明显’，你觉得这有可能吗？ADO/JDO的出现就是实现与任何数据库系统的封装，并提供统一的接口进行控制。
你的回答和实际的‘面向对象的数据库开发’原则离得太远，基本上是围绕着重现数据库存取引擎功能进行讨论。如果你能围绕企业中各种业务进行面向对象的分析的话，相信会有更多的人迎合你的观点。任何讨论这个主题的贴子中很少有人提出企业流程和业务逻辑。
‘业务逻辑与data source’，这里的Data Source应该是连接数据库的数据源设置，但并不影响我们的主题。你是不是看过论坛里的某个贴子？我记得里面就提到这个概念，但我觉得有些无奈。

to mycreatedream

我对这句话的理解是，随着系统（指一个具体的企业应用系统）越来越成熟，越来越能真实反应业务需求，它的数据结构会趋向合理，稳定，不会轻易发生改动。而且，也应该尽量避免改动，原由是：
1. 企业应用系统讲求数据源应该集中，整个架构是以单一的中央数据库为数据中心，在周边建立各个部门的子系统。也就是说数据库已经变成“公共财物”了。这样一来，任何一个子系统都不能轻易改变数据库结构，否则会牵连到其他子系统。
2. 随着数据库里的数据量越来越大，随便改动数据库结构。会带来数据迁移、旧的数据备份无法使用等等问题
3. 还有可能是，项目一开始数据库就已经存在了。项目小组由始至终都没有修改数据库结构的权限。

然而另一方面，业务规则是不停变化的。变化的原因是市场需求，政策等外部原因造成的，跟系统是否成熟没有关系。变化发生时，修改原则应该是把修改集中在业务逻辑代码上，尽量不触及数据源。这就引起了业务逻辑与数据源的（对问题域的）定义出现不同。

举个具体例子。一个工资系统，计算奖金（单位里“按劳分配”那部分）的代码一开始是作为储存过程A放在服务器上的。刚开始做系统分析的时候，有一部分人可以享受特别待遇。例如奖金可以按一定算法统一上调。那个时候判断是否上调没有特定标准，人事处手上掌握着这些人的名单（List1)。因此储存过程的处理方法是调用另一个储存过程B，判断一个人是否在名单里。

随着系统的推广，这个储存过程现在被好几个部门共同使用。因为要标准化流程，人事处制订了优待人员上调工资的具体条件。这样，人员名单就可以通过计算得出了。但是，为免引起民愤，原先受优待的人员仍然享受优待。因此，需要把两份名单整合起来计算奖金。但是，原来的享受优待的人员在其他部门也能享受一定优待，但符合奖金上调条件的新加入的人却还没有这样的待遇。于是，原来的名单必须单独保留，新人的数据不能合并到里面。于是，人事处只好保留原来的判断过程B,另做一个储存过程C来判断是否需要上调工资。显然，C里面复制了B里面的大部分代码，并加入新的整合两个表的代码。

好，现在新的ＢＯＳＳ上台了，为了刺激生产力，现在决定符合条件的人（无论在或不在原来的名单List1上）按一个新算法分级上调，不符合条件但在List1上的人，仍按原来的统一上调算法来计算。但其他部门的优待则除原先在List1上的人外，分级中进入前两级的新人也能享受。

至此，对于工资部门来讲，数据库结构已经与业务逻辑不统一了。因为原先的List1要减去符合条件的人，才能得出按原来统一算法上调的人。这个表不能直接使用了。而其他部门，也需要合并list1和按照算法算出来的人员。而且储存过程B和C都要改变，并且B中被C复制过去的那部分代码，在B改动时必须相应改动C。不要忘记，B和C里面不但包括纯粹的计算代码，还包括其实不需要改变的各种数据库访问代码在混淆视听。

当然，我举的这个例子只是初步开始发生业务逻辑偏离数据源的情况，不需要进行分层也可以轻易地统揽整个问题，完满解决。（如果我说一个复杂到超出了个人理解能力的例子，也没有意义）但可以预见，若这类问题多而频繁的发生，业务逻辑代码和数据源访问代码就有分开的必要了。

to gondsoft
> 在数据库应用中，我们面向的对象是什么？不就是数据库吗！

我的理解是，应该是面向实际问题域里的对象。例如要做一个音像制品销售系统，数据库里需要保留的对象只是ER图里会出现的ENTITY，例如CD，录象带，货架，订单、顾客等等。但实际问题域里的对象则远远不止这些，例如收入，折扣（Discount)...等等。如果要使用设计模式（常用的例如Strategy），更会加入一些中间对象。也就是所谓的Temporary Object与Persistent Object的区别。

> 现在我们需要做的就是将这些数据库对象和实际业务流程进行整合，所谓的整合
> 就是实现业务流程（即各个业务对象）中需要处理的数据对象，以实现业务逻辑。

这句并不是很理解，可以说得详细些吗？

关于业务逻辑与数据库的差别，我的观点在上面的帖子已经解释了。至于讨论方向偏向于O-R MAPPING，那是因为楼主的第一条帖子就是讨论O-R MAPPING的。其实OOA和OOD也是很多人很感兴趣的，我想我们可以交流一下。其实O-R MAPPING也是双向的，可以根据已有的关系数据库结构，设计MAPPER把它MAP到对象模型上去。但也涉及到如何根据OOD得出的对象模型来设计合理的关系数据库与MAPPER，把对象保存到数据库里。就例如JDO与BOLD所做的事。

> 业务逻辑与data source’，这里的Data Source应该是连接数据库的数据源设置

我所说的data source是指代码结构中presentation - domain model - data source（表达层-业务层-数据源层）中的data source layer。当然也包括了数据库连接，但大部分（或所有）访问数据库的代码（包括SQL STATEMENT）也包括在里面。

鏀剁泭涓嶅皯锛屽?涔

把数据库管理系统与具体业务分离，就会明白编程的真正对象应该是什么。