Для реінжинірингу нашого нового продукту ми зараз вибираємо найкращий фреймворк з Java. Оскільки слід розглянути підхід до агностики бази даних для моделі, ми працюємо над варіантами між Struts + Spring з iBATIS або Hibernate. Будь ласка, порада, яка найкраща, оскільки обидва пропонують наполегливість.
Відповіді:
iBATIS і Hibernate - це зовсім різні звірі.
Я, як правило, дивлюся на це так: Hibernate працює краще, якщо ваш погляд є більш об’єктивно-орієнтованим . Однак, якщо ви переглядаєте більше орієнтованих на бази даних, то iBATIS - набагато сильніший вибір.
Якщо ви повністю контролюєте свою схему і у вас немає надзвичайно високих вимог до пропускної здатності, тоді Hibernate може працювати досить добре. Об’єктна модель забезпечує досить зручний код, але з величезною вартістю складності.
Якщо ви маєте справу зі "застарілою" схемою бази даних, де вам потрібно писати досить складні SQL-запити, то, швидше за все, iBATIS буде працювати краще.
HQL (Hibernate Query Language) - це ще одна мова, яку вам доведеться вивчити, і навіть тоді ви, мабуть, знайдете випадки, коли вам все одно потрібно писати SQL. Більше того, є ймовірність, що ви десь витратите півдня на з’ясування правильної комбінації XML, властивостей, анотацій тощо, щоб Hibernate сформував ефективний SQL-запит.
На це питання не існує універсальної відповіді "А краще, ніж В".
Подумайте, чого ви намагаєтесь досягти. Як правило, модель розділення відповідей командного запиту добре працює для складних доменів.
Причина в тому, що ти намагаєшся зробити одну з двох речей, як правило:
Hibernate добре працює у випадку 1, що дозволяє вам просто скласти POJO та продовжувати / оновлювати його. Це також робиться швидко, якщо ваш домен не є досить великим.
myBatis чудово підходить для отримання запитів (випадок 2), коли ви просто хочете отримати відповідь. Hibernate спробує завантажити весь графік об’єкта, і вам потрібно буде почати налаштовувати запити за допомогою хитрощів LazyLoading, щоб він працював у великому домені. І навпаки, якщо ви просто хочете отримати якусь аналітичну сторінку POJO, реалізація myBatis того самого запиту буде тривіальною.
Через це myBatis працює швидше, ніж Hibernate при SELECTS.
Ці два випадки - це різниця між командами, де ви хочете змінити дані домену, та відповідями, де ви просто хочете отримати деякі дані.
Отже, розгляньте ці два випадки та те, що робить ваша програма. Якщо у вас є простий домен і ви просто отримуєте інформацію, використовуйте myBatis. Якщо у вас складний домен і зберігаються сутності, використовуйте Hibernate. Якщо ви робите обидва варіанти, розгляньте гібридний підхід. Це те, що ми використовуємо для нашого проекту, який має тисячі організацій, щоб тримати його під контролем. ;)
ORM проти стійкості
Hibernate - це середовище відображення об’єктів (ORM), яке відображає класи Java у таблиці баз даних. MyBatis - це система стійкості, а не ORM. Він відображає оператори SQL на методи Java.
Схема бази даних
Hibernate може створювати або перевіряти схему бази даних відповідно до вашої моделі Java, тоді як MyBatis не має такої функції. Крім того, це зручно для тестування середовища, коли ви використовуєте БД в пам'яті. Пов'язані обговорення:
Кеш
Hibernate має кеш першого рівня, який неможливо відключити. Це означає, що якщо ви запитуєте елемент через ORM, а потім видаляєте його безпосередньо за допомогою SQL, він залишається в кеші. Ви можете явно очистити кеш, щоб отримати найбільш оновлені результати з бази даних. Пов'язані обговорення:
Оптимістичне управління замком
Також є відмінності в оптимістичному управлінні замком:
MyBatis не підтримує оптимістичний контроль одночасності, на відміну від інструментів ORM, таких як Hibernate / JPA з анотацією @Version.
Пов'язані обговорення:
Ліниве завантаження
Hibernate спробує завантажити весь графік об’єктів, крім об’єктів, які позначені для ледачого завантаження. myBatis завантажить дані відповідно до запиту SQL. Ледаче завантаження може покращити продуктивність, але може призвести до витоків з'єднання, якщо воно використовується зі
<property name="hibernate.enable_lazy_load_no_trans" value="true" />
властивостями. Пов'язані обговорення:
Управління сеансом сплячого режиму
Такі операції, як збереження, оновлення або видалення, виконуються за допомогою Hibernate Session . Це вимагає чіткого розуміння того, як реалізувати правильну стратегію управління сеансом сплячого режиму, щоб уникнути, detached entity passed to persistта інших явищ, пов’язаних із сплячим режимом.
Іноді може знадобитися більше часу, щоб зрозуміти основну поведінку сплячого режиму, ніж додати трохи більше роботи та написати необроблені оператори SQL для myBatis.
Каскадні
Hibernate забезпечує каскадне скасування, видалення сиріт та інші функції для графіків об’єктів, поки вони відсутні в myBatis - для їх реалізації вам потрібно буде явно писати запити SQL.
Запити
У myBatis ви будете писати майже звичайні запити SQL. Hibernate має кілька варіантів формування запиту: SQL, HQL, API критеріїв. Іноді може бути доречним використовувати API критеріїв, коли у вас є багато необов’язкових полів у критеріях. Це забезпечить більш структурований підхід до формування запиту та, можливо, уникне пов'язаних з цим помилок.
Клет зробив велику роботу, підсумувавши це порівняння. Hibernate добре працює, коли ви керуєте моделлю даних і є більш орієнтованим на об’єкти, тоді як iBATIS працює добре, коли вам потрібно інтегруватись із існуючою базою даних, і є більш орієнтованим на дані.
Також я думаю, що Hibernate має трохи більше кривої навчання. З iBATIS досить легко дізнатись, що відбувається, тоді як із Hibernate відбувається більше «магії». Іншими словами, новачкам може бути iBatis простішим у використанні та розумінні.
Але я не кажу, що вам слід віддавати перевагу iBatis, iBatis та Hibernate просто відрізняються, як сказано вище.
І, до речі, якщо ви виберете Hibernate, можливо, розгляньте можливість використання стандартизованих анотацій об'єктів / реляційних відображень JPA та EJB 3.0 (JSR-220), наданих Hinonate Annotations .
Hibernate - це ORM, тобто (на самому базовому рівні) він відображає екземпляри об'єктів Java у фактичні рядки таблиці бази даних. Як правило, для pojo, отриманих через Hibernate: будь-які маніпуляції та модифікації цих pojo будуть відображатися в базі даних. Hibernate генерує та виконує відповідний SQL у відповідний час.
Mybatis (на самому базовому рівні) - це просто інструмент для поєднання та виконання SQL, який зберігається у файлах xml. Він не відображає екземпляри об'єктів Java у рядки таблиці бази даних, швидше він відображає методи Java у оператори SQL, а отже, це не ORM. Це також може повернути подзо, звичайно, але вони не прив'язані до будь-якого контексту стійкості.
Обидва інструменти роблять набагато більше, ніж описано вище, але один - це ORM, а інший - ні.
Я вважаю, що критерії, які дозволять вам вибрати, який із них використовувати, критично залежать від моделі бази даних, з якою вам доведеться працювати.
Наприклад, уявіть велику розгалужену схему, яка представляє якусь страхову модель. Розробники повинні отримувати дані та взаємодіяти з цими даними таким чином, що відповідає кожному бізнесу.
Розробник пішов, і ніколи не очікується, що він матиме необхідні бізнес-знання, щоб писати весь sql від руки (чого потребує Mybatis). Hibernate підійде для такого сценарію.
Бізнес-аналітики визначають модель даних, сутності, взаємозв'язки та взаємодії, як і їх досвід. Потім розробники Java використовують Hibernate для "прогулянки по моделі". Розробники бізнесу можуть швидко стати дуже продуктивними без необхідності писати складні помилки, схильні до помилок, щоб працювати на дуже складній схемі.
На мою думку, як Hibernate, так і Mybatis регулярно використовуються в одному проекті.
Де використовується Hibernate
і де використовується Mybatis
якщо ви вже використовуєте Spring, я б почав з Spring JDBC, а не занурювався прямо в Hibernate або iBatis. Якщо ви пишете свій рівень стійкості з точки зору інтерфейсів, у вас не повинно виникнути проблем з переключенням реалізацій після того, як ви отримали Hibernate або iBatis.
Немає жодної причини, чому це має бути рішення "все або ні". Використовуйте те, що найкраще підходить для вашої ситуації.