@arlen
以前我的想法与你一样。我在我们公司的一体化项目中极力推荐其他架构。但是由于各种原因最后还是用了这种table module架构。

结果发现，使用这种应用架构在强依赖于关系数据的应用中却是有效。

之前在看PoEAA中提到，能够与“TABLE”交互的接口越多这种模式约有效。
在实践过程中发现，其实只要提供一种通用的简洁的序列化方式既可。比如，在于界面交互式（尤其是HTTP的web方式）可以用JSON来实现序列化过程。对于数据库接口的交互其实就是一个加了循环的Record处理。

关于你提到的TABLE存储在那里？ 其实这个问题很简单，因为大部分企业应用都是“事务”应用所以，在一个Tx中提交这些数据到数据库就结束了。

很久没有上来了，那个一体化项目作了1年多了。呵呵。要好好总结一下。

我认为这个模式并不适于用在WEB开发上，象http这种无状态的会话，把“二维表”保存到哪是个让人头疼的问题。倒是适合可以把一堆数据加载到内存中的windows应用程序

Java中引入接口，从某种程度上说，是为了实现类似于C++的多重继承。相对于Abstract，它对字段和方法的要求更加严格。

详细的可以参考：http://www.blogjava.net/flyingis/archive/2005/11/02/17879.html

我认为接口是约定遵守的行为标准，具体怎么实现可以由各使用者自行确定。
所以一般技术标准都是以接口形式公布。可以方便各厂商自行实现。所以接口主要是对外的。
abstract更大程度上是应用在自己能掌控的内部，比如自己是软件开发商，那么在自己的系统里就可以大张旗鼓的使用abstract而不用考虑别人会怎么实现。
表达能力不好，说的不太清楚。也就是说如果有第三方实现的参与，最好用接口，如果是自己实现，接口和abstract都可以考虑

分页晚一点做，谢谢关注:)

我倒..早知道我也去抽个奖...

哈,正在看,有点感觉

我也BS一下 同时也羡慕ing....

看PEoAA时候就对这个模式一知半解，看了这篇文章大概了解原来自己是没有切肤之痛所导致

恩。。。 是的，许多事务组件其实已经实现了提到的所模式。我这里只是说明一下，原理而已。嘿嘿。。。

你说的乐观锁都是自己来创建.好象ADO.net自身也支持并发,ADO.net使用的是乐观锁.

欢迎交流:msn: cowbird2002@hotmail.com

@wfeng007
寒一下你的“杜撰”。如果文章是“杜撰”，随笔就是“谣言”了。呵呵。

我想 对于这样非常理论化的归纳 估计很多人都不愿意看。 不过作为以后杜撰文章的，可复用模块是不错的材料。。。。呵呵

写的很好啊。看上去象元模型。为什么不放首页呢？