300分请大家谈谈TDataset-TFields-TField体系的运作机制。(300分)

>>所以你以三层的架构来开发C/S程序，完全是没有必要。

我并不想用三层的架构来开发C/S程序，而是想利用Tprovider和TClientDataSet
更快更好的实现界面，业务规则，数据库三者分离。

用了Tprovider和TClientDataSet，怎么分开实现界面，业务规则，数据库三者分离！！！？？

如果界面，业务规则，数据库三者是分离的，那就意味着，数据库机构发生了变化，只要
修改APPSERVER，而界面不动，用了Tprovider和TClientDataSet，这可能吗？

为什么用了cds就不能分开实现界面，业务规则，数据库三者分离？？？？！！！

cds只是一个数据的装载体。无论你怎么做应用程序，你需要从用户处收集数据输入吧？
ok，我们假设从零开始，现在用户一次性输入了20个字段的内容，那么我们的程序应该
要从界面上把这20个字段的内容收集起来返回给调用输入的方法吧？好，我们可能会把
这20个字段装到一个list型的变量中去然后把这个变量返回给调用用户输入的方法，这
个方法当然后续就可以进一步处理，比如先调用某个业务逻辑函数来判断当前这些数据
的合法性，然后如果通过就保存到数据库中。。。。那么，既然我们在这里用了一个
list型的变量来收集传递数据，为什么这个list型的变量不可以是一个cds呢？用数据集
还可以让你免去一个一个界面元素收集数据到你自己的变量中的苦。本质上，一个cds难
道不就是起一个数组的作用吗？我们刚才的list变量不也是一个数组吗？把cds的delta
或data取出来，然后如果需要的话你完全可以把它的数据分解到对应的业务对象中，如
果你的应用逻辑并不是那么复杂，你也可以直接对这个data进行业务逻辑处理。有什么不
可以呢？？？

不是borland害了你，而是它给了你做小应用的快速框架。但是你在做大应用时也不自己动
动脑子变通变通就套用做小应用的框架，当然是越做越麻烦了。事实上，各位的应用中，
业务逻辑真的有这么复杂吗？用牛刀之前不妨先确认一下自己杀的是鸡还是牛，如果是鸡，
抄起牛刀来，你就更麻烦更得不偿失了。

>>如果界面，业务规则，数据库三者是分离的，那就意味着，数据库机构发生了变化，只要
修改APPSERVER，而界面不动，用了Tprovider和TClientDataSet，这可能吗？

不明白你的意思。

我非常同意你说的DELPHI提供的是“小应用的快速框架”。
DELPHI缺乏企业级应用的平台，太单薄了，什么东西都要自己动手来做，十分不爽。

>>DELPHI缺乏企业级应用的平台，太单薄了

这句话我同意。

由于最近在忙考试，没有时间试用bold。今天看了看bold的相关文档（doc.boldsoft.com），
在这里说说我的理解。请京工之鸟看看有没有误解的地方。

总体来看，bold提供了一个Domain Model (业务对象)+ Data Mapper（数据映射）的架构。
而且有几个很主要的特色：

1) 能根据rose，modelmaker，或它自带的designer设计的uml中自动生成delphi或c++的类源代码
以及相应数据表

2) 每一个概念上的业务对象对应用作管理的list对象和表示个体的对象。这不是强制性的结构，但
根据文档看来似乎使用这种结构最能发挥bold的效力

3) 使用concept object的概念，把内存中的对象和数据库中的（假想）对象统一起来。
设计时不用考虑何时实例化对象，由bold架构来决定何时从数据库读入对象数据。（基本
上，读入数据的原则是尽量延迟，仅当一个对象被实际访问的时候，才读入持久数据。因此
如果对一个list进行扫描操作时，则需要用ensure方法显式批量读入数据并实例化对象来提
高效率。）

4) 使用了subscription机制来提供对象属性级的trigger（或者说event）。感觉上subscription
类使用了类似Decorator模式的机制，可以根据需要依附到某个对象上为其提供trigger。

5) 提供了一些界面控件来辅助界面设计。它们主要是面向List型对象的，例如grid和treeview等

6) 自动数据库共享控制

7) 提供XML与COM的支持。（这方面我不是太熟）

8) 对ocl（Object Constraint Language）的支持。
（之前我从没见过ocl这个词，请问哪里可以找到相关文档？）

一个由bold生成的类大概是这样的：
1) 具有业务属性。（例如Person类有FirstName，LastName等，
属性类型为在uml设计中的原始类型，例如integer，string等）
2) 具有与业务属性对应的BoldAttribute对象。例如FirstName会有一个对应的M_FirstName，
类型是TBAString。估计在这些BoldAttribute类中有处理subscription机制以及其他一些
实现Bold架构机制的代码。但因为看得仓促，没弄清为什么要把它们作为public的属性。
3) 具有用于与其他类关联的属性。通常是一些自动生成的List类（对多关系）或单独的类
变量（一对一关系）。例如表达一个person住在一个地址，但拥有多栋楼房里，会有
Home：TBuilding和OwnedBuildings：TBuildingList属性
4) 在uml中定义的类方法。
5) 一些bold预定义的方法。例如constructor和destructor。值得注意的是，这里的constructor
和destructor都是在概念意义上的。也就是说，是在内存与数据库统一起来的空间里的。构造
一个持久对象，表示在数据库中添加这个记录（当然，是更新的时候才实际加入）。而析构一
个持久对象，表示在更新时，数据库中同时删除这个记录。至于普通意义上的构造和析构，也就
是什么时候在内存实例化对象，由bold架构来负责。编程人员大部分情况下是不用管的。

总体来讲，bold给我的感觉是很完美地提供了Domain Model＋Data Mapper的机制。使用它所
生成的业务类可以实现开发期的数据库透明。也就是说使用这些业务类来编程的人员也不用管
数据库细节了。但前提是要具有数据库完全控制权，因为数据表也是bold根据需要自动生成的。
如果数据库已经在使用，或者由于外部系统的关系，有特别的设计要求。也许bold就无能为力了

UP

漏了一点，bold还提供内存对象和数据库操作两方面的事务机制支持

to kidneyball,
ocl在bold带的文档里有。

to 沙隆巴斯的主人,
delphi缺乏企业级应用的平台，bold就是用来解决这个问题的。
在企业级的应用delphi并不是很普及，主要也是这个原因。我想
这也是为什么borland为什么要把bold作为架构版的原因。

不过我感觉我用C/S就能解决大部分问题了,数据感知控件我也用,
不过不在里面修改,编辑的,客户端也快100个了,速度还不错呢.

多人接受答案了。

这么快就结贴了？ 遗憾