Плюсы и минусы - HibernateUtil против @Autowired SessionFactory - PullRequest
1 голос
/ 13 марта 2019

Я пытаюсь лучше понять плюсы и минусы того, как мы можем использовать Hibernate.У меня есть опыт работы с HibernateUtil.java, в котором я звоню, чтобы установить / получить сеанс для взаимодействия доступа к данным.Тем не менее, я поддерживал приложения, которые используют свойства @Autowired для реализации SessionFactory внутри DAO.Если не очевидно, мы используем 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();
      // ...
   }


}

Мне любопытно, почему один метод будет использоваться поверх другого.Есть ли разница в производительности или потреблении памяти между ними?Сталкивались ли вы с случаями, когда инъекция боба мешает эффективно выполнять задачи?Должен ли класс обслуживания создавать экземпляр DAO для доступа к его методам, или вы предпочитаете использовать статические методы?

Какие еще плюсы и / или минусы приходят с каждым вариантом против другого?

ПРИЧИНА ЗАКРЫТИЯ ЭТОГО ВОПРОСА

После прочтения более подробно об этом,Я понимаю, что это вопрос, основанный на мнении, и я не получу количественного ответа.Это сводится к синглтон против инъекции зависимости.Это широко обсуждалось, и я прочитал основные аргументы о том, когда использовать, а не использовать каждый.Я думаю, что есть дискуссия о том, должен ли Hibernate быть сконфигурирован как Singleton или DI, но переполнение стека не место для этого обсуждения.Привет.

1 Ответ

2 голосов
/ 14 марта 2019

Большая часть обоснования, сделанного создателями Spring, заключается в том, что часто вы хотите иметь возможность менять конфигурации для простого тестирования.Разделение кода и конфигурации, а также позволить платформе соединить их для вас значительно упрощает тестирование, потому что вам не нужно писать код специального случая для переключения между тестовым режимом и режимом prod.

Если вы используетестатический способ, ваша HibernateSessionFactory и конфигурация, использованная для ее создания, жестко закодированы, либо у вас нет возможности протестировать другую реализацию, либо вам нужно написать собственный код, чтобы сделать это.

Если выИспользование Spring-Boot, вы можете иметь разные профили настроить Hibernate по-разному.Тривиальным примером может быть использование Hibernate H2 для локального запуска и модульного тестирования, а также использование базы данных не в памяти в других местах.Spring позволяет вам декларативно определять этот материал с помощью конфигурации Java и аннотаций.Вы указываете, какие конфигурации работают для каких профилей, и вы можете передать профиль как системное свойство при запуске кода, или аннотировать ваши тесты, чтобы указать, какой профиль они используют.

Перед загрузкой Spring вы можете сделать нечто подобное, когда в тестах используется специфичная для теста конфигурация Java или context.xml.

С помощью Spring-Data JPA большинство ваших DAO становятся интерфейсами, в которых выможет использовать существующие методы CrudRepository или иметь несколько пользовательских запросов в аннотациях.Spring обрабатывает много деталей реализации для вас, это гораздо меньше работы, чем написание ваших собственных DAO.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...