[因为CSDN限制长度，所以无法全部贴出]
[如果大家有兴趣，可以去我的博客看看 http://blog.sina.com.cn/u/1247584292 ]
与Spring整合
意义何在？
首先，这似乎是一种流行的趋势，网上随处可见讨论Struts + Spring + Hibernate的文章。但是，除非你确切的知道这几种框架整合的优点和缺点，否则盲目的一拥而上，只能带来代码结构上的混乱和调试的困难。 当我将Spring与Hibernate整合的时候，看重的是Spring提供的这三种功能：IoC，AOP和模板（指HibernateTemplate）。其中IoC（控制反转、依赖注入）可以降低类之间的耦合度，但除非你在设计的时候就谨守依赖接口，而非实现类的原则 ，否则不是一个IoC就能解决所有的问题。下面的例子我们就会看到，虽然使用了IoC，但是类间的耦合度并没有本质性的降低 。AOP其实是我愿意冒着增加系统复杂度的风险而引入Spring的主要理由，借助它来实现EJB中的CMT（容器管理事务，也就是声明式的事务处理）实在有点诱人。毕竟，这两年随着切面（Aspect）的概念越来越深入人心，程序员再难以容忍在业务逻辑中加入许多业务无关的技术代码（比如事务处理）。还记得上一章的末尾中我们讨论过的service模型吗？AOP可以解放里面的冗余代码。但在开始接触这个激动人心的新特性之前，我必须再次声明引入AOP的风险：复杂度！为了现实AOP，我们必须将Service，DAO，SessionFactory，甚至DataSource层层管理起来，为了避免为每一个Service进行一长串切面声明，还可能用到Spring中的自动装配和继承……当然，据我所知，对于一些“天才”的代码爱好者来讲，这也不算什么。最后说说模板，模板自然是减少代码冗余，并在一定程度上规范代码（DAO部分）的一个好方法。我的建议是，如果你已经决定要将Spring整合进来，那就革命的彻底点，让DAO依赖于模板吧；否则，不要因为想使用模板而选择Spring，毕竟，有时间的话，我们也可以自己写一个。Well，读者也许会奇怪为何我在这里不合时宜的一再强调整合的风险。反正无论我说这么，你肯定会看完这一章，并且尝试去整合Spring和Hibernate，那就在实践中体会一下吧。
[如果大家有兴趣，可以去我的博客看看 http://blog.sina.com.cn/u/1247584292 ]
与Spring整合
意义何在？
首先，这似乎是一种流行的趋势，网上随处可见讨论Struts + Spring + Hibernate的文章。但是，除非你确切的知道这几种框架整合的优点和缺点，否则盲目的一拥而上，只能带来代码结构上的混乱和调试的困难。 当我将Spring与Hibernate整合的时候，看重的是Spring提供的这三种功能：IoC，AOP和模板（指HibernateTemplate）。其中IoC（控制反转、依赖注入）可以降低类之间的耦合度，但除非你在设计的时候就谨守依赖接口，而非实现类的原则 ，否则不是一个IoC就能解决所有的问题。下面的例子我们就会看到，虽然使用了IoC，但是类间的耦合度并没有本质性的降低 。AOP其实是我愿意冒着增加系统复杂度的风险而引入Spring的主要理由，借助它来实现EJB中的CMT（容器管理事务，也就是声明式的事务处理）实在有点诱人。毕竟，这两年随着切面（Aspect）的概念越来越深入人心，程序员再难以容忍在业务逻辑中加入许多业务无关的技术代码（比如事务处理）。还记得上一章的末尾中我们讨论过的service模型吗？AOP可以解放里面的冗余代码。但在开始接触这个激动人心的新特性之前，我必须再次声明引入AOP的风险：复杂度！为了现实AOP，我们必须将Service，DAO，SessionFactory，甚至DataSource层层管理起来，为了避免为每一个Service进行一长串切面声明，还可能用到Spring中的自动装配和继承……当然，据我所知，对于一些“天才”的代码爱好者来讲，这也不算什么。最后说说模板，模板自然是减少代码冗余，并在一定程度上规范代码（DAO部分）的一个好方法。我的建议是，如果你已经决定要将Spring整合进来，那就革命的彻底点，让DAO依赖于模板吧；否则，不要因为想使用模板而选择Spring，毕竟，有时间的话，我们也可以自己写一个。Well，读者也许会奇怪为何我在这里不合时宜的一再强调整合的风险。反正无论我说这么，你肯定会看完这一章，并且尝试去整合Spring和Hibernate，那就在实践中体会一下吧。
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货