1

当我们将hibernate与spring集成时，我们通常实现@Repository spring注解使用的基于注解的方法。我了解到这样做的目的是为了消除我们 dao 中的 spring 依赖，并且由于 hibernate3 支持上下文会话来管理会话

@Repository
public class HibernateSpitterDao implements SpitterDao{

privateSessionFactorysessionFactory;

@Autowired
public HibernateSpitterDao(SessionFactory sessionFactory){
  this.sessionFactory=sessionFactory;
}

private SessioncurrentSession(){
  return sessionFactory.getCurrentSession();
}
...
}

例如，如果我们不使用基于注解的方法，我们的 dao 将直接依赖于 spring 特定的类，比如需要扩展 HibernateDaoSupport。

但是即使有了注释，DAO 仍然依赖于 Spring 知道吗？因为@Repository 是spring注解。我们不能完全独立于春天知道吗？它更像是依赖弹簧注释而不是依赖弹簧类，是吗？

我只是想一段时间后我们需要用其他东西来切换弹簧。在那种情况下，如果我们的 DAO 与 spring 的依赖关系为零，我们根本不需要接触我们的 DAO。

4

2 回答 2

4

要实现完全解耦，您将不得不摆脱注释，就像您已经发现的那样。要么，您必须使用 spring 基于 XML 的配置，或者您创建一个@Configuration类（也称为基于 java 的配置）来构建您的 bean 工厂。

我只是想对你的想法发表评论。花时间在一个完全解耦的解决方案上，理由是“也许在未来的某个时候我们会想要切换”对我来说听起来像是浪费了很多时间。您是否有任何理由怀疑或假设这种转换将在可预见的将来完成，或者永远？你的去耦是有代价的，这很清楚。您必须维护 XML 文件和/或配置类，而不是易于查看的注释，这两者往往会变得相当复杂，并且在一段时间后难以概述。

于 2012-09-03T08:47:14.160 回答
0

我会说您提供的示例并不紧密依赖于 Spring。您使用的唯一 Spring 组件是 @Repository 注释，它 1) 充当 @Component 并让您对类进行组件扫描，以及 2) 使您的类有资格进行数据访问转换 ( Source )。

这根本不会将您的实现与 Spring 耦合。相反，您使用的是 Hibernate 的会话工厂，并且您与它耦合。没关系，您的实现与 Hibernate 相结合。

事实上，这就是定义接口并拥有不同实现的全部目的。在这种情况下，您有一个 SpitterDAO 接口和一个 HibernateSpitterDAO 实现。如果您将来决定使用 iBatis 或 Spring 的 HibernateTemplate 或 JDBCTemplate，您可以编写不同的实现。

春天大部分时间都试图避开你。它主要用作管理依赖注入的容器，实际上只是协调您的代码如何“粘合在一起”。我认为当你的类实现了 ApplicationSessionAware 和 BeanPostProcessor 之类的东西时，代码会与 Spring 紧密耦合，我会尽量避免这种情况。

只是因为我不确定你是否知道 SessionFactory 和 Spring 的 HibernateTemplate 之间的优缺点，这里有一篇来自 SpringSource 比较和对比它们的精彩博客文章：http: //blog.springsource.org/2007/06/26/所以你应该仍然使用springs-hibernatetemplate-andor-jpatemplate/

以下是博客文章中的最终建议片段：

所以简而言之（正如 HibernateTemplate 和 JpaTemplate 的 JavaDoc 已经提到的），如果您开始在新项目中分别使用 Hibernate 或 JPA，我建议您直接开始使用 Session 和/或 EntityManager API——请记住：Spring 尝试是非侵入性的，这是另一个很好的例子！

于 2012-09-03T09:24:25.283 回答