优点 vs 缺点 - HibernateUtil vs @Autowired SessionFactory答案

【问题标题】：Pros vs Cons - HibernateUtil vs @Autowired SessionFactory优点 vs 缺点 - HibernateUtil vs @Autowired SessionFactory
【发布时间】：2019-08-04 15:11:59
【问题描述】：

我试图更好地了解我们如何使用 Hibernate 的优缺点。我有一个 HibernateUtil.java 的经验，我在其中调用以建立/获取用于数据访问交互的会话。但是，我维护了利用 @Autowired 属性在 DAO 中实现 SessionFactory 的应用程序。如果不明显，我们使用的是 Spring MVC。

下面是一些如何使用它们的简要示例：

方法A

public class MyDao {

   public static void save() {
      Session session = HibernateUtil.getSessionFactory().getCurrentSession(); 
      session.beginTransaction();
      // ...
   }

}

方法B

public class MyDaoImpl implements MyDao {

   private SessionFactory sessionFactory;

   //... getter/setter for session factory

   public void save() {
      Session session = getSessionFactory().getCurrentSession(); 
      session.beginTransaction();
      // ...
   }


}

我很好奇为什么会使用一种方法而不是另一种方法。两者之间是否存在性能或内存消耗差异？您是否遇到过注入 bean 妨碍有效完成任务的情况？服务类是否应该实例化 DAO 的实例以访问它的方法，还是您更喜欢使用静态方法？

每个选项与其他选项相比有哪些其他优点和/或缺点？

结束此问题的原因

阅读更多关于此的内容后，我意识到这是一个基于意见的问题，我不会得到定量的答案。这归结为单例与依赖注入。这已被广泛讨论，我已经阅读了关于何时使用和不使用每个的主要论点。我认为应该讨论 Hibernate 是否应该配置为 Singleton 或 DI，但 Stack Overflow 不是讨论的地方。问候。

【问题讨论】：

研究为什么单例不好，依赖注入好。

标签： java hibernate autowired sessionfactory

【解决方案1】：

Spring 的创建者提出的大部分理由是，您经常希望能够更换配置以便于测试。分离代码和配置并让框架为您将它们放在一起使测试变得更加容易，因为您无需编写特殊情况代码即可在测试模式和生产模式之间切换。

如果您使用静态方式，您的 HibernateSessionFactory 和用于创建它的配置是硬编码的，并且您无法选择针对其他实现进行测试，或者您必须编写自己的代码来执行此操作。

如果你使用 spring-boot，你可以让不同的配置文件以不同的方式配置 Hibernate。一个简单的例子是让 Hibernate 使用 H2 在本地运行和单元测试，并在其他地方使用一些非内存数据库。 Spring 允许您使用 Java 配置和注释以声明方式指定这些内容。您可以指定哪些配置适用于哪些配置文件，并且您可以在运行代码时将配置文件作为系统属性传递，或者注释您的测试以指示它们使用的配置文件。

Pre-Spring-boot 你可以做类似的事情，其中测试使用特定于测试的 Java 配置或 context.xml。

使用 Spring-Data JPA，您的大多数 DAO 都成为接口，您可以在其中利用预先存在的 CrudRepository 方法，或者在注释中可能有一些自定义查询。 Spring 为您处理了很多实现细节，这比编写自己的 DAO 工作量要少得多。

【讨论】：