A
一个Delphi Programmer的痛苦是很多的，特别是Delphi Database programmer,尽管Delphi被鼓吹为最佳的Database programming language--此话不假，但是我们的痛苦并没有因此而减少。
任何一个曾经做过delphi databsae Application的Programmer都会有这样的痛苦：我们不得不为我们的application添加一个new feature，但是似乎却无从下手；我们的database structure结构改变了，所以我们不得不花大量的时间去修改我们的program，即使前者是小量的改动；我们要离开公司了，newbie来了，但是我们却无法清晰地告诉他（或她）我们程序的结构，甚至连我们自己也不明白了；又接到客户的电话了，我不得不修改界面，但是，似乎改动的地方超乎我的估计--糟糕，为什么这个button始终不变灰，终于在别人的代码里找到原因了；我们的程序已经不能修改了，它们快爆炸了；我们不得不重做--于是再一次的噩梦开始了。
很羡慕Java programmer，他们是幸福的，至少他们获得幸福的机会远大于我们，他们可以拥抱J2EE，后者可以说强制性地要求他们的Program呈现良构。还有很多open source的工具在等着他们的选择(castor, jboss, enhydra等)，这些工具也给他们提供了设计良构程序的机会。
不用惊讶于二者之间的天壤之别，这是所有Delphi programmer应得的，除非我们从根本上改变。在众多的Delphi programmer中，他们了解database有时甚至超过了解Delphi本身，因为，几乎所有的Delphi programmer在进行database programming的时候，他们面向的是data，是record，Field， Primary Key， Index这些数据库概念，很可笑，在oop口号如此响亮的今天，我们却不得不面向数据。
B
关于数据库的封装问题， 这实际上牵扯到一个效率问题， 在J2EE的框架中， 提出了真正面向对象的Session Bean与Entity Bean， 以及对应于此的许多工具， 比如像IBM的sanfrancisco工程，Castor等，他们的出现标志着O/R mapping技术的成熟与走向实用， 但是在Java中， 使用它们的话，效率是比较低下的（每一个Ejb Container可以承受高达几十万个的EJB，即使在这种情况下，效率也低下）， 所以如果在Delphi中实现O/R Mapping的话，其效率问题一定是一个瓶颈。（关于O/R Mapping,可以参见http://www.thoughtinc.com/上面的cocobase）； 另外一个实现的途径是面向对象的数据库（它就像O/R Mapping一样可以直接从数据库中Query一个对象， 或将对象流进数据库）， 可是这个方面的应用非常生涩， 到目前为止， 它的应用还处在可以说是萌芽阶段，因为现有的关系数据库应用程式要转向面向对象的， 需要很大的成本， 其次就是关系型的数据库及其对应的产品非常成熟与丰富， 这也是面向对象数据库不足以流行的原因（参照http://www.odbmsfacts.com/object-database.htm以及面向对象的查询语言OQL--http://www.odmg.org/）。
附：
三层架构的状态问题
这个问题的确比较让人头痛--在delphi的Midas情况下， 但是只要有了O/R Mapping存在的话， 它就可以解决了。 必须记住的是，是不可能从逻辑上避免无状态的， 所以有状态对象的存在是必然的，问题在于如何理清哪些对象应该是stateless， 哪些是statefull的。
客户属性定制问题
不错，这是一个非常头痛的问题。如果将它转化进技术领域， 那么它就成了这样一个问题了--对象动态界面问题（所谓界面， 是指对象暴露给client的interface，比如在Delphi中的Public及Published部分， 或者是一个接口）， 换句话说就是如何动态的决定一个对象的属性，在Martin fowler的《分析模式》中，有关于这个方面的详细论述，大家可以去参考一下， 在Delphi里面的实现思路就像TField这个类的定义一样， 在TField中， 给定了一个属性那就是Data Type， 另外就是Type Check，这些都可以被用来进行动态属性的设计。另外，楼上有个兄弟说得好， RTTI与Visitor的合作也有异曲同工之妙！
8356
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
