如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件

确实比较像桥接模式，但桥接模式是对类中的某个方法进行抽象，即桥接模式能使类在运行过程中动态地确定某个方法的实现，但这似乎还不是本方案的基本目的。
本方案的基本目的是使我们的业务系统不依赖于spring系统，即一个系统与另一个系统的解藕。从这样一个思路来讲更应当理解为一个适配器模式（虽然并不是标准的适配器模式），DaoSupportHibernate3Imp或DaoSupportHibernateImp是那个适配器，业务系统提供DaoSupport接口与外界交流，然后通过那个适配器与spring衔接而又不依赖于它。

本质上说，LZ的还是用代码级别的封装，以达到屏蔽具体实现这种古老的方式。做这种封装粒度难以控制，粗了则不够用，细了则极其烦琐，维护成本也很高。想象一下系统会使用如此众多的Third-party的Jar包吧，难道你都要封装？难道只会升级Struts,spring,hibernate?

LZ只提到了产品Non-Functional方面的升级，其实产品很关键的还有Functional的升级，在这里就不谈Functional的升级，
对于Non-Functional的升级，jar包升级是一方面，还有一方面是完全的功能性，甚至是整个实现的升级，比如从传统web升级到RIA。代码封装这种低级别的实现是没有办法做到的。

对于真正的产品公司，一般不会采用低级别的代码封装，从大的方向看，我的建议是
1. 选对你的第三方框架
2. 采用高度抽象的元数据描述系统，采用代码生成方式
3. 做好你的核心引擎

JJYAO谈的问题我的理解是对于第三方产品是否需要解藕，这个问题正如我在《（原创）一个优秀软件开发人员的必修课：GRASP（2）低耦合》中提到的，耦合不好，但过度的解藕也不好，关键看你自己的需求。现在我提出解藕，是因为我看到了不同版本的hibernate和spring存在的差异需要我们解藕，以适应各个版本的差异带给我们的影响。

持久层的接口只需要很少的几把函数就可以了
save(Object) 用于insert
update(object) 用于 update
executeUpdate(sql or hql)
executeQuery(sql or hsql)

不管啥业务，都是以上几把函数的组合，
调用入口多了，就会混乱
四把函数就足够了
没必要为每个实体去写DAO，因为都是通用的

我同意,我们可以通过泛型类型绑定,可以多个实体公用一个DAO,大量减少了代码量.

伴随着JDK1.5被广泛使用，利用范性可以很好地解决大量DAOs的问题
可以参考http://www.hibernate.org/328.html

拜师不敢当，相互交流，我的MSN：fan_gang2004@hotmail.com，没有QQ。

虽然泛型可以简化很多的问题，但不用泛型也可以解决大量DAOs的问题。在我以后的版本中，整个DAO层只有一个BasicDao和它的接口GeniricDao。你可以参考一下我后面写的博客的附件。

这样做是使得持久层简单了很多，但我觉得大型开发还是不大妥当。
参数是sql/hql的话，就把这些sql/hql写在业务逻辑层service里面了。我觉得这样做不大合适。我还是喜欢sql/hql全部都在DAO里面，虽然DAO大了，但要统一维护sql/Hql简单很多了。也做到了分层的实际意义，不然你一个DAO提供这些传入sql/hql的方法，那也只不过是一个数据库入口而已吧。

实际上，按照我的理论，在不论DAO或BUS中都不再写任何hql/sql，也不再需要任何表连接。我们执行任何表更新或查询的操作都是针对单个值对象的操作，然而这单个值对象实际上包含了与它相关的所有表的信息。比如“员工”表，其值对象已经包含了它的部门的属性，我们在查询的时候只是查询“员工”对象，不需要将“员工”与“部门”进行关联查询。当然，hibernate在实现的时候当然需要表关联，当对于DAO和BUS根本就不用考虑这些，它们只需要以对象的思维，运用hibernate的一对多、多对一、多对多、继承的关系，去操作值对象就可以了。这也是DAO的基本思想所在。
当然，我们不能否认，hibernate的值对象关系在处理异常复杂的查询和报表的时候是脆弱的。当你在处理这些东西的时候，不论是DAO、值对象、hibernate，还是hql其实都不是好的方案。直接采用sql和jdbc也许更合适一些。

真是受益匪浅啊 自己只知道用 但是从来也没有考虑这些 惭愧啊 向楼主学习