SSH的柜架中如何才能运用好设计模式呢！

很简单，引入领域建模，Evans DDD。抛弃数据库编程。

所以，SSH并不是DDD框架，除了让你开始觉得好玩以外，并不能给你带来革命性思维改变。

把SSH改了再来用，通过充血模型去做，将一些业务的东西分成有状态和无状态的，分别交给领域或者通过Service去处理领域，可以试着简化Action的功能，把编程重点放在Service，然后在Dao做缓存工作。

单纯的SSH，也许并不复杂，整合好了换种思路去用就是了。

上面的描述不清楚，Service是调用逻辑，不是在Service中写逻辑。

我是这么认为的。

其实我觉得SSH限制了领域模型,简单的应用用领域模型做起来比较麻烦.

不知道大家使用SSH的有没有这种感觉?

没有楼上说的感觉，简单应用更方便用领域，因为模型不会太复杂。

to saharabear
可能小弟我还没修炼到家吧。

在您的团队是运用领域模型吗?

我们的领域模型如果也能获得IOC的支持就好了，那样充血的模型可以获得依赖注入的优势。但是SSH做不到。

我们的项目，如果有机会使用领域模型，肯定要使用的，并且目前已经证明了成效，当然也因为水平问题，有些时候也会碰到困难，但整体来说还是用领域模型比较好。

关键问题是，我们有些项目如果无法使用DDD的，比如原有系统的维护，就比较麻烦，我在这也发过贴报怨过，但总体就一条：走在正确的路上才能方便。

但再加一条：我们并不追求富血模型，我们只能是：如果能充血就充血吧，但有些时候的现实的阻力寸却没办法。

楼上说的“我觉得SSH限制了领域模型,简单的应用用领域模型做起来比较麻烦.”

非常正确，我认为尤其是Hibernate限制了领域模型，Hibernate对于领域模型是很重的，这不能怪Hibernate，因为它只是一个ORM框架，不是一个真正领域模型持久化框架。

因为是ORM框架，所以Hibernate更多引入了数据库概念，但是又没有完全向OO程序员屏蔽这些关系数据库概念，所以，我们的领域模型结合Hibernate以后，反而被拖累了，在这方面，对象数据库是一个值得探索的方向。

从我个人来看：应该抛弃数据库这个Box盒子，这个单点，持久化框架应该是一个很轻量甚至程序员都没有觉察的框架，就象我在另外一个帖子说；它能够自动持久，无需我们来照顾。比如我们可以引入JMS专门做持久，这样可以彻底将持久和业务领域模型彻底分离，但是JMS又太重，也许并行计算中线程executor等是一个方向，但是线程接触太多又不好：

领域建模中的对象如何睡在数据库中:
http://www.jdon.com/jivejdon/thread/35047.html

Hibernate阻碍领域模型更重要的一点是：Hibernate没有完整提供领域模型的生命周期的Factory，Hibernate使用一级缓存Session来保存它创建的实体，但是这个缓存只是请求级别，不是application级别，领域模型应该是生存在application级别的内存中，那么我们就要配置Hibernate的二级缓存，但是Hibernate的二级缓存是为查询等优化的，而且是封闭的，不透明的，有时我们需要控制一些模型在保存二级缓存之前做一些特别业务处理，就很难做，还不如在Spring中间层自己做一个缓存，这就回到了JiveJdon的设计思路上来。

什么思路？就是要自己来处理对象的生命周期，来处理一些微妙的有关生命周期方面问题，因为缓存是对象的生存空间，如何保证缓存中某个对象实例的唯一性，是实现缓存的共享，还是实现prototype模式的对象复制，这些都需要依据值对象和实体特征确认和区别，如下：
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34936&message=23118451#23118451

没办法，公司里的框架把自由的空间都给抹杀了！
所做的依然是面向数据库的编程！
我也想用领域建模来提高自己的建模能力，但是几乎没这机会。

bang 有时我们需要控制一些模型在保存二级缓存之前做一些特别业务处理

这句话不太理解，保存到二级缓存之前要做一些什么样的操作呢？