А ось так мені показували:
Якщо знайдеться людина, яка пояснить різницю між підходами і що робить кожен метод, буду дуже вдячний.
У першому варіанті я не розумію, де додаються параметри конфігурації? А в другому не розібрався, як саме задаються properties. Я так розумію new Configuration (). AddProperties (properties). ідентично new Configuration (). configure ( "hibernate.cfg.xml")
Якщо я не правий поправте: спочатку Properties properties = new Properties () ;. А потім потрібно методом put () додавати різні властивості.
заданий 5 Січня '16 о 20:23
У всіх випадках SessionFactory будується в три кроки. 1) Тим чи іншим способом отримати Configuration. 2) За Configuration побудувати StandardServiceRegistry за допомогою StandardServiceRegistryBuilder-а. 3) За StandardServiceRegistry побудувати SessionFactory за допомогою Configuration. В останньому випадку ймовірно помилка. Замість return new Configuration (). Configure (). BuildSessionFactory (standardServ# 8203; iceRegistry); напевно треба було написати return cfg.buildSessionFactory (standardServiceRegistry); - Sergey 6 Січня '16 в 6:48
@ АлександрТіщенко new Configuration (). AddProperties (properties) не ідентичне new Configuration (). Configure ( "hibernate.cfg.xml") - v.ladynev 17 Січня '16 в 0:24
Зачитує конфігурацію з hibernate.cfg.xml і hibernate.properties. Повинен працювати у всіх підверсії Hibernate 4 правильно.
hibernate.cfg.xml зачитується тут configuration.configure ()
Ось це applySettings (configuration.getProperties ()) необхідно, щоб не втратити properties з hibernate.cfg.xml (в цьому файлі можна вказувати властивості так само, як в hibernate.properties). Наприклад, якщо у Вас там властивості не вказані (а зазвичай вони там не вказуються), то досить ось цього
Взагалі, ця негарна метушня з ServiceRegistryBuilder через те, що додатковий тюнінг конфігурації винесли в окремий клас, а buildSessionFactory () необачно зробили @Deprecated.
У Hibernate 5 взагалі хотіли викинути клас Configuration і перейти до конфігурації з використанням StandardServiceRegistryBuilder і MetadataSources. З javadocs Configuration Hibernate 4.3
NOTE. This will be replaced by use of StandardServiceRegistryBuilder and MetadataSources instead after the 4.0 release at which point this class will become deprecated and scheduled for removal in 5.0. See HHH-6183, HHH-2578 and HHH-6586 for details
Далі, в Hibernate 5, судячи з усього, від цієї ідеї відмовилися і даного зауваження в документації до Configuraton немає.
hibernate.properties зачитуються збоченим чином в статичному ініціалізатор класу Environment. Тобто, при першому зверненні до нього. Це, швидше за все, відбувається тут new Configuration ().
Працюватиме тільки починаючи з версії Hibernate 4.3, так як тільки починаючи з цієї версії присутній клас StandardServiceRegistryBuilder. Ви можете счіается, що StandardServiceRegistryBuilder - це те ж саме, що і ServiceRegistryBuilder. Починаючи з версії 4.3 ServiceRegistryBuilder був позначений, як @Deprecated. а весь його вміст було скопійовано в StandardServiceRegistryBuilder.
метод configure () не викликається, то відповідно, інформація про маппинге з файлу hibernate.cfg.xml зачитуватися не буде. Взагалі, цей підхід можна розглядати як неповний варіант третього підходу.
Цей підхід буде працювати правильно починаючи з версії Hibernate 4.3 (через уже згаданого StandardServiceRegistryBuilder). Але він містить надмірність, про яку згадав @Sergey. Якщо прибрати надмірність, то цей варіант зведеться до
Що є тим же самим, що перший підхід, так як StandardServiceRegistryBuilder - це те ж саме, що і ServiceRegistryBuilder.
Як робити краще за все
Правильніше за все робити ось так
Основна причина, на мій погляд, це те що все вишеперічісленних підходи на будуть взагалі (!) Правильно працювати з Hibernate 5. Про це докладніше можна почитати тут.
Хоча buildSessionFactory () оголошена як @Deprecated в Hibernate 4, в Hibernate 5 вона запив назад! Відповідно, вищенаведений код буде правильно працювати у всіх версіях Hibernate.
Вказівка шляхів до файлів конфігурації