@Jack.Wang
你误导了太多的人。。
。。。。。
现在对于常量池的解释一片混乱。
说 在堆区 在栈区 在静态区 在数据区 的都有。。
妈的。。。

不错。。。还有研究 dump文件的阿 不错不错呵呵

朋友是bea的？ 。。。 我们公司用了spring作了框架 然后再weblogic中 redeploy的话似乎spring的context没有被销毁。 我们已经在listener中调用了context的关闭销毁方法但是似乎没啥效果。。。 redeploy多次后java heap就不行了。。。 不知道其他地方有没有这种情况？？？？？

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

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

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

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

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

4.1是周六。。。 还上班。。。 上班还出事故。。 真背啊。。。

我们公司有个部门 就使用这个作为界面基础的。。。。不过。。。性能好像有点问题。。。

事实上 即便自己觉得理解了 还是会跟你所讲的原意有所出入。。。 。。。 hoho

为啥要用 斜体字。。。 看起来实在难受啊。。。。。。。。。。。。。。。。

只谈结构是否缺少行为表述呢？？还是认为结构描述先天由于行为描述？？


“.....着它们处于复杂性的不同级列（可以实现平滑的过渡）...”
又看到这个词了 -_-b

楼主的注释写错了。。。 被注册到shutdownhook上的是TestShutdownHook的实例作清理工作的也是TestShutdownHook的run() 他将无限循环的TestThread.run()中止了。

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

。。。jdon 还是有些份量的。。。 和javaeye 一样 都是有年头的。。。

还有 抽象 本身不只是软件工程的东西，而是哲学的东西，软件工程只是借用。

比较期待 你的来自自然科学 级列论

不要用某些人啦。。。 那个只是我个人观点啦。。。。

......对于你的一般性 基本知道是根抽象性有区别了 。。。。。。不过说老实话 相对论没zm学 所以还是不太理解你举的例子 能不能举个 通俗点的例子。。。

关于

service层, data object层, dao层
其实 只是分析到某个抽象层次。。。职责 分类。。。而且有个问题环境 就是“ 交互型应用来说的”

你说：“. 但实际上, 我们肯定可以想见更加复杂的情形, 仅仅三层并不足以充分表达程序的结构”
确实是这样，然而问题是就像你批评说的“有哪么复杂么”。既然，大家都知道，过于复杂就无用的。哪只分析到一个一般人能够接受的复杂程度就停止。难道有错？
其实我只是想说明 问题出在人们在实现中滥用这些东西 。分析出这些东西的本身无可厚非。

还有：关于你举的例子 你说的只有 crud。。。 这里假设你所指crud是 这些方法或函数以及参数就是 服务接口的职责 其实更service 处于同一职责。。。 crud内部比然有对状态的处理以保证这些crud的功能就是预想的那样。。。 其实些东西的更 domain object 层次职责一样。 （说老实话 data object我没有看到过）
dao层 与 crud 中直接跟你的“数据库” 交互的部分 其职责也使相近的。

如果要按照你的级列理论来说： 这里的职责也更你举的例子是不同纬度的级列层次。

怎么不发到 架构师之家来呢？

我也寒一下。。。。。。。。。。。。。。。看来你学到了模式的精髓了。。。。。

不知道可不可以这样理解。
你所指的“一般”与“特殊”就是： “相对抽象” 以及 “相对具体”。
你所指的“一般”到“特殊”，“特殊”到“一般”连个方向就是指：具化过程，抽象泛化过程，这两个过程。

而级列就是指“相对抽象” 与“相对具体”存在着不同抽象层次。而且这写层次客观存在并且连续。

关于 你所说的“偏偏要在service层, data object层, dao层”部分可能你没有理解定义这些层次的原始意义。 这些东西只是对“职责”的描述并不是实现，在实现中应该根据实际情况进行合并与取舍。而且这些“职责”也是由“事务”(这里并不是指原子操作的概念)这个职责具化而来。 我想你也应该知道一旦具化（特殊化），适用范围就变小了。

不错啊。。。 以前还没用过这个。。。 先收了

haha... OO 被你们讨论成这样 我也够佩服的。。。

我觉得你们去证明或取否定基础都没有意义。。。
因为：
1。OO本来是哲学概念。
2。OO是用来描述的，不是用来计算和证明的。
3。任何体系都没有办法证明自己的正确性，而只是基于一些公理存在，而这些公理指在于信与不信。


不过我觉得还是很有分量的。。。 先收了。。。。

对于“可退化性“ 不太了解
请问 根据你的定义
“架构的可退化性(degragation)指的是架构的结构可以从元素比较丰富,层次比较多,比较复杂的情况退化到比较简单的情况“

是不是 退化就是指 不同职责部分 的合并但是这些职责依然存在？

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

我个人感觉还是，比较接近的。
之所以现今的软件架构与建筑架构有较大差异，主要是因为软件领域和建筑领域的发展阶段不同。一个几十年，一个上千年了。成熟度不一样。如果类比现今的软件领域和早期的建筑领域会发现很多共同点的。

不错不错。

软件架构师注重整体把握，高级程序员负责细节精华。者这个观点来说，两者级别是一样的，只是关注点不同。

“另外作为架构师还要考虑的问题很多，甚至比技术架构更重要如授权模式、部署模式及成本、维护方案、安装及升级方案、商标及商标的相关元素、发布及发布管理、安全因素、市场因素及技术市场架构（个人认为这个因素最难也最重要）“
。。。。。。。。。这个好像已经上升到系统分析级别了。。。该角色关注范围比构架师跟广。

你好，算我一个把。软件构架师我是我职业生涯的的一个中期目标。现在虽然经验项目经验不多，不过我自以为对事务系统的整体多少有点把握。现在，正准备总结一下自己在这方面的一些观点，并准备花较常时间学习研究一下软件集成的设计与构架。刚申请blog 现在上还没有啥东西。。。http://www.blogjava.net/wfeng007