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

大家都来看

to forss:
我采用修改过的Socket连接。我认为既然已经有了个第三层就省了SocketServer吧。
呵呵，DBClassBuilder正是我要做的不同的是：我除了生成Object级的代码还可以直接
生成三种方式的界面代码：
Web Form/InspectorStyle Form/General Controls Form
我有联系方式是：
电话：13899033300
E-Mail:barton131420@163.com
你的呢？说来可笑，我不打算自己当老板了，准备找一家大一点的公司呆呆。

up

我以前也考虑过界面，业务规则，数据库三者分离的设计方法。当时采用的是
先设计业务规则和功能，再设计数据库的方法。

用员工信息来举例吧，业务类有Temployee，用来处理员工的增、删、改和规则检查。
Temployees类是Temployee的聚合，另外还承担批量处理的任务。Temployee和Temployees
的所有对数据库的操作都由TemployeeDB负责。不管员工信息是单表存放还是多表存放TemployeeDB
都是一样处理。

虽然Temployee和TemployeeDB之间仍然存在耦合，不过基本上算是分离了业务规则，数据库。
但是最后我放弃了这种设计，原因是界面。按照我的设计，界面只能和Temployee打交道。
这就意味着数据库控件不能用了，报表也不能用了。

当时也考虑到改写tdataset应该可行，但是时间太紧，最终还是放弃了。
barton是我所知的第一个吃螃蟹的人，不知你能不能谈一下你这方面的经验?

to barton:
是改写TDataset-TFields-TField体系的经验。

在Flower的书中，前面几章是关于各种模式的整体观念。我发现它们能解决许多朋友的一些
关于面向对象在enterprise application中的问题。所以有机会的话还是把它们译了放上来
吧。但这些文章比较长，而且不象介绍模式的文章那样有代码范例来占占篇幅。而小弟考期
将近，只能每次译一部分了。下面是关于分层的第一部分。

Layering (1)

--------------------------------------------------------------------------------

Layering是一种很普遍的技术。软件设计者用它来把复杂的软件系统分成多个部分。你可以
在计算机架构中看到分层结构，从调用操作系统的编程语言，到设备驱动程序和CPU指令集，
到集成晶片中的逻辑门。网络中有在TCP层之上的FTP层，而TCP层在IP层之上，IP层在
ethernet之上。

当你从分层的角度去想一个系统的时候，你可以想像软件中的主要子系统被安排成分层蛋糕
的样子，每一层都放在一个较低的层上。在这个方案中，较高的层使用较底层所定义的各种
各样的服务，但底层并不知道高层的存在。而且每一层通常向高层隐藏了比它更底的层。这
样，第4层使用了第3层的服务，第3层又使用了第2层的服务。但第4层并不知道第2层。并不
是所有的分层架构都象这里描述的这样不透明，但大部分是。或者说，是几乎不透明的。
（译注：我发现“透明”这个词常常用来表示两个完全相反的意思，说A对B透明，某些著作
中是指B根本不知道A的存在，即比喻义为A是整个透明的，而在另一些著作中，是指B不但知
道A的存在，而且了解A的细节，即比喻A的外壳是透明的。本文中的“透明”指的是后者，
那么“不透明”就是指A封装了底层细节。）

系统分层具有许多重要的好处。

1. 你可以把一个单独的层作为一个连贯的整体来理解，而无需知道太多其他层的细节。例
如你可以理解怎样在TCP的基础上建立一个FTP服务，而无需知道关于ethernet的工作细节。

2.你可以用另一个提供相同基础服务的替代品来替代一个层。一个FTP服务不经修改就可以
在ethernet、PPP、或者电缆公司使用的任何一种标准上运行。

3.你可以把各层之间的依赖最小化。如果电缆公司改变了它的物理层运输系统，但它保证该
系统能使IP正常工作，则我们不需要修改我们的FTP服务。

4.层为标准化提供了一个很好的地方。 TCP和IP是一种标准，因为它们定义了它们所在的层
如何运作。一旦你建立了一个层，你可以用它为许多更高的层提供服务。因此TCP/IP被
FTP、telnet、SSH、http等使用。否则，所有这些高层协议都必须提供它们自己的低层协
议。

分层是一种很重要的技术，但它还是具有缺点的。

1.层把一些东西封装得很好，但并不是全部。因此你有时候得进行层叠性（cascading）的
修改。一个典型的例子是在一个分层的企业级应用程序中，需要加入一个在UI中显示，而且
要在数据库中储存的字段。这样，你必须在UI和数据库之间每一层都加入相应的处理。

2.额外的层会降低性能。在每一层中，信息通常需要从一种表达形式转换成另一种。但是，
封装低层功能常常会为你提供大于代价的效率。一个控制事务的层可以被优化并因而使所
有事情都处理得更快。

然而，分层架构中最难的部分是在于决定应该有哪些层和每层的职责。


企业应用中分层的发展

虽然我太年轻了，因此没有参与使用批处理系统的年代中的任何项目，但我能感觉到在哪
个年代的人并不关心分层。你写一个程序来处理某种形式的文件（ISAM, VSAM，等等），
这就是你的应用程序了。不存在任何的分层。

90年代，客户－服务器（c/s）系统的壮大使分层的观念变得明显。这是一种两层的系统：
客户端包括了用户界面和其他应用程序代码，服务器通常是一个关系数据库。普遍的客户端
工具是VB, Powerbuilder和Delphi。这些工具使建立数据处理应用程序变得特别容易，因为
它们提供了具有SQL感知功能的界面控件。这就使你能通过拖拽控件到一个设计区域来建立
一个屏幕界面，然后通过设置正确的属性来把控件和数据库连接在一起。

如果应用程序都是关于显示和简单的关系数据更新，那么C/S系统工作得非常好。问题出现
在业务领域逻辑（domain logic）：业务规则，检验，计算等等。通常人们把这些东西写在
客户端。但这种做法显得笨拙而且常常把这些逻辑直接嵌入到屏幕界面中。当domain logic变
得越来越复杂的时候，这些代码变得非常难以处理。而且把逻辑嵌入屏幕界面的做法使重复
代码很容易出现，这意味着很简单的改动将导致在许多屏幕界面的类似代码中搜索修改点。

一个替代的做法是把domain logic放在数据库系统里作为储存过程（stored procedures）。
但是stored procedures只提供了很有限的结构化机制，这样又再次导致了笨拙的代码。而
且许多人喜欢关系型数据库是因为SQL是一个工业标准，允许他们改变数据库提供商。尽管
实际上较少的人会真正地改变数据库提供商，但许多人喜欢不需要很高代价就能做到这件事
的自由感。stored procedures都是平台相关的，因此使人们失去了这种改变提供商的选择。

在c/s系统普及的同时，面向对象的世界也在壮大。面向对象的世界有一个解决domain
logic难题办法：改变到一个三层系统。在这种方法中，你有一个表达层（presentation layer）
来安置你的用户界面，一个业务层（domain layer）来处理你的domain logic，还有一个数
据源。使用这种方法，你可以把所有复杂的domain logic从你的界面代码中移到一个层中，
在那里你可以用面向对象的方法合理地处理它们。

尽管这样，面向对象方法并没有流行起来。（原文：Despite this the object bandwagon made
little headway）实际上是，许多系统是很简单的，或者说至少是从简单开始的。虽然三层
的方法有许多好处，但如果你的问题很简单，使用c/s的各种工具是很吸引人的。而这些
c/s工具很难，甚至不可能，用于三层的环境中。

我想这时出现关键性转变在于互联网（web）的发展。突然间，人们希望在一个网页浏览器
中实施c/s应用。但是如果你所有的业务逻辑都掩埋在一个“胖”客户端（rich client）
中，那么所有这些业务逻辑都必须在网页界面中重做一次。而一个设计良好的三层系统只需
要加上一个新的presentation就能完成任务。而且，通过java，我们看到面向对象语言成为
了主流。为建立网页而出现的工具并不与SQL紧密结合，因此更需要一个三层系统

当人们谈到分层（layering），常常会混淆layer和tier这两个术语。（译注：看中文书的
朋友是绝对会混淆的，因为都译作“层”。因此在这段中将直接使用英文layer或tier，后
文中的tier也使用英文）通常，这两个词是用作同义词的。但许多人认为tier暗示了一种
物理上的分离。c/s系统常常被描述为two-tier系统，它的分离是物理上的：客户端是一台
台式机而服务端就是一台服务器。我使用layer来强调你并不需要在不同机器上运行这些
layer。一个domain layer常常运行在台式机或数据库服务器中运行。在这种情况下，你只
有两个结点（nodes）但有三个不同的layers。你可以在一台本地台式机上运行所有的三个
layer，但它们仍然是不同的三个layer。

The Three Principal Layers
三个主要的层

在这本书中，我把我的讨论集中于一个有三个主要层的分层结构：表达层（presentation），
业务层（domain），和数据源（data source）

Presentation逻辑是关于如何处理用户和软件之间的交互。这可以简单到一个命令行或者
一个基于文本的菜单系统。在现在，它更可能是一个胖客户端的图形界面或一个基于HTML的
浏览器界面。Presentation的主要职责是向用户显示信息和截获用户对于domain和data source
的命令

Data source逻辑是关于如何与其他系统通讯来完成对应用程序有益的任务。它可以是事务
监测器，其他应用程序，消息系统（messaging system）等等。对大多数企业应用来说，
最大的data source逻辑部分是一个主要负责储存持久数据的数据库。

剩下的部分就是domain逻辑了，它常常也被叫作业务逻辑（business logic）。这是这个应
用程序需要为你所工作的领域所做的工作。它涉及到基于输入和储存的数据的运算，检验所
有从presentation来的数据，和根据在presentation中得到的命令精确地算出如何调遣
data source逻辑。

一个单一的应用程序常常为这三个领域设立多个包（packages）。一个被设计为可以由最终
用户通过胖客户端来操作，但同时可以通过命令行来操作的的应用程序具有两个
presentation：一个为胖客户端所设，一个为命令行所设。多数据源组件可能呈现了多个不
同的数据库，但都是为了与已有的packages进行通讯。即使是业务也会被分为相对独立的几
个不同领域。特定的data source可能仅仅被特定的业务packages使用。

到现在为止，我们都是谈到用户，这自然会引出一个问题：如果不是一个由一个人类来使用
这个软件情况会怎样。这可能一件新的而且时髦的的东西，例如一个互联网服务，或者是
一些平凡而且有用的东西，例如一个批处理过程。这这种情况下，用户是一个客户程序。这
时，presentaion和data source层会变得明显的类似，因为它们都是关于如何向外部通
讯。这就是在Alistair Cockurns 六边型架构模式背后的逻辑。这个模式把任何系统形象
化为一个被外部系统包围的核心。在这个六边型结构中，所有外部的东西都基本上是一个
外部接口，这样它形成了一个对称的视图，而不象我这种不对称的分层方案。

但是，我发现不对称的方案非常有用，因为我想区别开你提供服务的接口与你使用其他服
务的接口是非常有用的。在这个基础上，我实际地分开了presentation和data source。
Presentation是一个你的系统向外部事物提供服务的接口，而不管这个事物是一个复杂的人
类或者是一个简单的远端程序。Data source是外部事物向你提供服务的接口。我发现考虑
这些分别是非常有用的，因为这些客户形式的区别会改变你对这些服务的思考方法。

层：Presentation
职责：服务的提供，信息的显示（例如在窗口中或HTML），处理用户请求（鼠标点击，键
盘按键，http请求，命令行参数）

层：Domain
职责：系统中处理的真实逻辑

层：Data source
职责：与数据库，消息系统，事务管理系统和其他packages通讯

使用domain logic的一个最难部分似乎在于人们常常发现难以区分什么是domain logic，
什么是其他类型的逻辑。一个很好的例子是有人告诉我这样一个系统。在这个系统中有一
个产品列表，表中所有比上个月的销售量提高10%的产品都显示为红色。他们实现这个效果
的做法是在presentation层中比较本月与上月销售量，如果提高了超过10%，他们就把颜色
设成红色。

麻烦在于这样做是把domain logic放到了presentation。要正确地分离各层，你需要一个在
domain层的方法来判断一个产品具有正在提高的销售量。这个方法比较两个月的销售量并
返回一个布尔值。这样，presentation层仅仅简单地调用这个方法，如果它返回true，则
把产品强调显示为红色。用这种方法，这个过程被分成两部分：一部分判断是否有产品需要
强调显示，另一部分决定如何强调显示。

我对于把这种做法过度地教条化感到不舒服。当检阅这本书时，Alan Knight发表意见说
他“被撕成两边，一边觉得把这些代码全部放进UI代码里是迈向地狱的第一步；另一边觉
得这是一种非常合理的做法而仅仅有一个教条主义者反对这样做”。令我们觉得不舒服的
原因是上面的两种描述都是对的。

~~~~ to be continued ~~~~~~

收起来先!tks

Laying (2)

When to separate the layers
什么时候进行分层

虽然我们可以为每一个范例鉴别persentation，domain和data source这三个普通的职责层，
但每一个范例都有它们各自关于它们如何分离各层的问题。如果每一个职责层都相当复杂，
这样把它们分拆为独立的模块是有很有意义的。一个具有复杂逻辑的应用程序应该为presentation、
domain、和data source设立不同的包。实际上，它可能有更进一步的中间层。但比较简单
的系统可能并不如此。如果你要做的所有事情是显示和简单的数据输入，那么把所有逻辑都
放到一系列的服务器网页（server pages）中去是非常合理的，特别是如果你手头有工具能
使编写这些服务器网页变得很容易的时候。

需要分离这些职责的复杂度并不是很容易就能确认的。我不能说如果你的domain logic的复
杂度大于7.4的时候，你就应该把它从presentation中分离出来。（除非我把计算复杂度作
为一个练习留给读者，我猜我就能够这样做了。 译注：也许是讽刺一些教科书作者把自己
都无法解决的问题留给读者作为练习吧）我的经验是，几乎在任何时候，都应该把presentation从
domain/data source中分离出来。我会违反这个原则的唯一情况是：如果domain/data source的
复杂度几乎等于0，而且我手头有工具能非常方便地把所有东西放在一起。一个典型的例子
是许多在SQL数据库之上建立的使用界面。它保证了presentation与数据库结构非常匹配，
而且很少涉及任何检验和计算，这样我就会使用把所有东西放在一起的做法。但一旦检验
和计算开始变得复杂，我就会把它分离到不同的对象中去。

我倾向于对不分离domain与data source有更大的容忍力。对许多简单的应用，这两部分可
能看上去非常相似，这样的话我更倾向于把它们放在一起。但一旦我组织业务逻辑的方式开
始看上去显得与data source的定义不同，我会希望把它们放到不同的模块中去。

当描述应用程序的分层结构的时候，我喜欢使用一个UML package diagram来展示packages
和它们之间的依赖。我在这里并没有提供一个作为例子，是因为实际的依赖与你使用的模
式非常相关。一个颇为抽象的规则是：任何东西都不应该依赖于presentation。任何在domain与
data source的模块都不应该调用presentation中的任何东西。当presentation需要根据
domain中的改变进行更新的时候，这种做法可能会导致问题。当这种情况发生时，你应该使
用一个Observer模式来避免对presentation的依赖。

对于其他更复杂的规则，我们必须了解更多关于模式的细节才能草拟出依赖的情况来。

Choosing where to run your layers
选择在哪里运行你的层

在这本书中，我主要谈及逻辑上的层：把一个系统分为各自分离的部分来减少系统不同部分
之间的耦合。即使这些层都运行在一台物理的机器上，分离这些层是非常有用的。但系统
的物理结构在某些方面会造成不同影响。

对大部分IS应用程序来说，选择在于一个处理是否应该在一个客户端，一台台式机上运行；
或者它是否应该在一台服务器上运行。

通常来说最简单的情况是把所有东西都放到服务器上运行。这样做的一个好方法是使用一个
运用网页浏览器的HTML前端。把所有东西都放到服务器的最大优点在于所有东西都易于更新
和维修，因为它们在数量有限的地方里。你不需要担心如何把它们分发到许多台式机中并保
持它们都与服务器保持同步。你不需要担心与其他桌面软件的兼容问题。

对于这种在服务器上运行一切的偏好，最大争议在于响应能力和离线操作。任何在服务器上
运行的逻辑都需要一个服务器传输回路（server round trip）来响应用户做的任何事。如
果用户想乱动一下界面上的东西又希望立即看到反馈，那么这个回路就成为障碍了。另外，
采取这种方案的应用程序需要一个网络连接来运行。网络似乎在任何地方都有，但我能够这
样说的前提是，我并不是在31,000英尺的高空。网络可能很快就能在任何地方都有，但有许
多人希望在现在就开始工作，而不用等到无线通讯覆盖到Deng End Creak（译注：信息闭塞
不通的Creak印第安部落）的时候。离线操作带来了一些特定的问题，但我恐怕在我的这本
书中不会涉及这些东西。

在存在这些普遍的影响因素的情况下，我们就可以逐层地看看我们能够作何种选择。

Data source几乎总是仅仅在服务器上运行。例外的情况是你能功能性地把服务器复制到一
个合适的强大的客户端中。这种情况通常发生在你希望离线操作的时候。在这种情况下，
在离线客户端上对data source进行的修改需要与服务器进行同步，正如我前面所讲，我决
定把这个问题留到另外一天来讨论－或者留给另外一个作者来讨论。

关于在何处运行presentation的决定因素大部分在于你希望使用什么类型的用户界面。使
用一个胖客户端几乎总是意味着你需要在客户端上运行presentation。使用一个网页界面
几乎总是意味着在服务器上运行presentation。但也有例外的情况，客户软件的远端操作
（例如在UNIX世界中的X服务器）在桌面电脑上运行一个网络服务器，但这种例外非常罕见。

如果你正在创建一个B2C（Businass-to-customer）系统－你没有选择余地。任何汤姆，迪克，
和哈里特（译注：即是任何人）都能连接到你的服务器上，而且你不想有任何人由于坚持在
一台TRS-80上进行在线购物而被拒之门外。在这种情况下，你在服务器上进行所有的处理并
为浏览器提供它们能处理的HTML。你选择使用HTML带来的限制是：客户下的任何一个的决定
都需要一个从客户端到服务器的回路来处理，这样会损害响应能力。你可以通过使用浏览器
脚本和可下载的applets来缓解这种情况，但它们同时减低了你的浏览器兼容能力，常常会
带来更多的头痛。你能尽可能使用越纯正的HTML，你的生活将会越轻松。（译注：pure HTML，
即不包含script和applets的HTML）

即使你的台式机上任何东西都是由你的IS部门度身定做的，轻松的生活仍然显得可望而不可
及。你仍然需要保持客户端是最新版本，和避免与其他软件的兼容性冲突。

人们希望使用一个胖客户端presentation的主要原因是一些任务对于用户来说太复杂了，
因而需要一个更有用的应用程序来提供比网页界面更多的东西。但是，越来越多的人开始
习惯如何使网页前端更有用，因而减少了对胖客户端的需求。当我写这篇文章的时候，我
非常喜欢一个原则：如果你能够的话，使用网页表示；如果你别无选择的话，使用胖客户
端。（web presentation if you can, and the rich client if you must）

剩下的就是domain logic了。你可以在三种运行业务逻辑的方式中选择：全部在服务器；
全部在客户端；或拆开它。再一次提醒，所有东西都放在服务器是一个实现简单维护的简
单方法。而把它放到客户端的需求来自响应能力和离线操作。

如果你必须在客户端上运行部分业务逻辑，你可以考虑把它全部都放在那里 － 至少通过
这样做，它被全部放在一个地方。通常这种做法会与胖客户端结合起来－在一台客户端机
器中运行网页服务器并不会明显地提高响应能力，虽然，这可以成为一个处理离线操作的
方法。在这种情况下（指把所有domain logic放在客户端），你仍然可以保持你的
domain logic在与presentation分离的模块中，事实上，你可以使用Transaction Script
模式或Domain Model模式。把所有domain logic放在客户端的问题是你为了升级和维护必须
做更多的东西。

把domain logic拆开到台式机和服务器听起来是两个世界（译注：指全放到客户端和全放到
服务器）中最差的办法，因为这样做的话，对于这些逻辑碎片中的任何一个，你不知道实
际上应该属于哪一边。导致你这样做的主要原因是，当你仅仅有一小部分domain logic必须
放在客户端。一个小诡计（译注：trick，一些不合常规的小技巧）是把这些逻辑碎片的隔
离到一个自包含的模块中，这个模块不依赖于系统中的任何部分。通过这样做，你可以在客
户端和服务器的任何一边运行这个模块。实现这个方法需要相对多的令人厌烦的欺诈技
巧－但它是实现这种分离工作的一个好方法。

一旦你选择好你的处理结点，你就应该尝试把所有代码放到一个结点，一个进程（process）
中。除非你绝对有必要，否则不要尝试把层分离到不同的进程中，因为这样做会导致性能
下降和增加复杂度，因为你必须加入更多的东西，例如Remote Facdes模式和Data Transfer
Objects模式

More Layering schemes
更多的分层方案

我精选出这三个层是因为这三个主题（subject matter）经常出现，而且我想这三层代表
了对企业应用来说有意义的最简单的分层方案。你可以用不同的方式去分层，而且这些不
同的分层方式往往是很有用的。但我发现把这三层放在心上总是有用的，而其他分层办法
虽然常常有用，但不总是有用。

我将会通过看看一些在其他有用的关于IS架构的书中提倡的分层方案，来举例说明这个观
点。首先是我称作Brown Model的分层方案。Brown Model有五层：Presentation,
Controller/Mediator, Domain, Data Mapping, 和Data Source。基本上，这个模型在基
础的三层之间都加入了附加的中间层：在presentation和domain层之间加入了
controller/mediator层，而在domain和data source之间加入了data mapping层。

我发现在某些时候分出这些中间层是有用的，但并不是所有时候。因此，我会把中间层作
为一种模式来讨论。Application Controller是一种在presentation和domain之间的中间
层。而Data Mapper是在data source和domain之间的中间层。在组织本书的时候，我把
Application Controller放在presentation的部分，而Data Mapper放在data source的部
分。

Brown Fowler
Presentation Presentation
Controller/Mediator Application Controller
Domain Domain
Data Mapping Data Mapper
Data Source Data source

因此对我来说，附加的中间层－常常是有用但不总是有用－代表了一种在设计中可以选择
的额外做法。我的做法是：总是考虑三个基础层，看看他们中是否有任何一个过于复杂，
如果有，加入中间层来进行功能分离。

另一个J2EE的分层方案出现在CoreJ2EE模式中。在这里，各层分别是：client,
presentation, business, integration, 和resource. 在business和integration层中存
在着简单的对应关系。他们（译注：CoreJ2EE的设计者）把由integration层连接的外部服
务称作resource层。主要的不同在于他们把presentation层根据运行的地点不同分为了
client（在客户端运行的部分）和presentation（在服务器端运行的部分）。这常常是一
个有用的分离，但再一次提醒，并不是所有时候都需要这种分离。

CoreJ2EE Fowler
Client Presentation that runs on client (eg rich client systems)
Presentation Presentation part that runs on server (eg http handers, server pages
Business Domain
Integration Data source
Resource The external resource that the data source in communication with

微软的DNA架构定义了三个层：presentation, business, 和 data access。它们直接和我
在这里使用的三层对应。最大的不同在于数据在data access层向上传递的方式。在微软的
DNA中，所有层都对记录集（record set）进行操作。这些记录集是一些位于Data Access层
的SQL查询的结果。这样就引入了一个明显的耦合：business和presentation层都需要知道
数据库结构。

我看待这个模型的方法是：在DNA中，记录集扮演了各层间Data Transfer Object的角色。
business层能够在记录集向presentation传递的途中对它进行修改，甚至自己创建一个记
录集（虽然这种情况很罕见）。虽然这种通讯形式在很多方面来看是很笨拙的，但它具有
一个很重要的优点：允许presentation使用数据感知的GUI控件，这些控件甚至对经过
business层修改的数据仍然有效。

Microsoft DNA Fowler
Presentation Presentation
Business Domain
Data Access Data source

在这种情况下，domain层被组织为Table Module的形式，而data source层使用Table
Data Gateways模式

~~~~~~~ End ~~~~~~~~~~~~~~

我想知道

学习一下bold，大概你会发现点什么新东西：）

bold是一套面向对象的应用框架，通过他，你可以使用delphi建立完全的面向对象的体系。你可
以在rose、modelmaker或其他支持uml和ocl的设计工具（或直接在bold内置的设计器中设计）中
设计及建立你的应用程序的模型。然后通过模型，可以直接生成用delphi代码描述的应用程序框
架。这样可以大大的缩短项目开发从分析阶段过渡到设计阶段的时间，提高开发速度。并且以模
型来管理系统框架将使你的系统更加的坚固和可维护。

bold的架构和具体的使用范例在它的帮助文件中都有。但使用bold，首先必须掌握和精通uml、
ocl、oop和delphi。

如果你要真正理解bold的作用，首先，请抛开用delphi写数据库程序的固有思路来理解。要是你能
在完全不用delphi的数据感应控件、数据集体系的情况下用面向对象的思路来写一套数据库应用，
你要怎么设计怎么实现？其中会遇到什么困难？有什么是可以抽出来成为体系和框架以便下一次项目
时可以重用的？想清楚这些问题，然后，ok，在bold中找找：）它帮你实现的就是这些问题中的某一
大块（注意不是全部）：）

看完这篇帖子，解决了困惑我许久的难题！谢谢楼上的所有人！

我现在用的也是一记录一对象的方式！ 这个叫Detail类也叫结构类
所有的对象全部用储存过程来操作。这样就有
形成对对象操作的类 这个类叫 DB类也就是数据操作类
DB里就有Get Insert Delete Update 等一些方法。
再在这上面加一个商业的一些东西就形成 Mng类
不过这样代码量很大！我写的代码起码有
20万行。在两个月内搞定。^－^ 我是用了源码生成器！！
总共有 180个表。
500个存储过程。但这样操作起来就各自之间很独立！
改一个字段名，绝不要改BusinessRules这要改动 DB 和Detail 就行！

源码生成器????


什么东西?

不太了解这些面向对象的数据库

假如有个TEmployee吧，若我登陆时，是不是就用TEmployee.UserLogin('username', 'userpass')呢？

若是在修改员工资料时呢？

TEmployee.ModifyInfo(...)这里面要带多少参数呢？？

是不是说把所有对此员工表的操作都提出来，组织成一个对象呢？？

我现在只是把大多数的工作都组织成了一个个的函数，放在当前窗口单元里。

因为提交数据时，有好多个字段需要检测合法性，而在不同功能模块里，提交字段数量又不同

迷惑中。。。还是不解

这个叫Detail类也叫结构类
就是对应一个表或者视图的所有字段
TEmployee.ModifyInfo(...) 就带这个Detail就行了呀！！

http://www.delphibbs.com/keylife/iblog_show.asp?xid=300

沒人催進度的時候用這種方法還可以

DY

copy

好贴子