Невже варто зупинитись на впровадженні агностика?


22

У мене є проект, над яким я зараз працюю, використовуючи Tomcat, Spring 4, Spring Security, MySQL та JPA w / Hibernate.

Я обрав JPA з точки зору того, що, мабуть, зробити заміну базового впровадження постачальників ORM безпроблемним або, принаймні, менш болісним. Я б сказав, що це подумки з використанням специфікації щодо впровадження (JAX-RS) є позицією за замовчуванням спільноти розвитку Java.

Мені цікаво, чи справді це завдання, яке варто виконати. Я впевнений, що якби я використовував Hibernate безпосередньо, я набув би певної сили, оскільки міг би використовувати функції, які не входять до основної специфікації JPA.

Частина мого занепокоєння випливає з ідеї YAGNI. Я по суті програмую в певному стилі та способі (використовую JPA замість сплячого), щоб у якийсь момент в майбутньому я міг змінити свою реалізацію ORM. Я сильно сумніваюся, що коли-небудь трапиться протягом життя продукту, тому я по суті докладаю зусиль для чогось, від чого я, мабуть, ніколи не пожинаю переваги.

Які ваші думки? Чи варто "програмування на інтерфейс", якщо мова йде про такі речі, як JPA? Ви коли-небудь фактично поміняли всю продукцію ORM у продукт? Чи вам колись вдалося повністю уникнути абстрагування чогось подібного до протікання JPA? В мене особисто вже є єдиний вихідний SQL-виклик (щоб очистити таблиці баз даних), і є щось, що я хотів би з цим вбудувати в специфікацію JPA (отримати / встановити префікси до ваших методів та різницю між ЧЛЕНОМ OF / IN, яка прив'язує себе лише до основної реалізації, отримає мені будь-який шанс уникнути.


Ви одиничний тест? Вимкнення реалізації не обов’язково означає готовий продукт.
MrDosu

Відповіді:


26

так що в якийсь момент в майбутньому я зможу змінити свою реалізацію ORM. Я сильно сумніваюся, що коли-небудь трапиться протягом життя продукту, тому я по суті докладаю зусиль для чогось, чого я, мабуть, ніколи не скористаюсь перевагами

На мій досвід, типовий корпоративний проект ніколи не витісняє:

  1. База даних
  2. ОРМ
  3. Мова

Я не знаю цифр, але відсоток дворівневих додатків, які я бачив, реалізують, а потім змінити одну з цих речей, ймовірно, буде менше 10%. Якщо це трапляється, це рідко, і зазвичай це відбувається протягом перших 2-3 місяців проекту, коли люди ще знаходяться в режимі виявлення. Більшість систем, яких я знаю, досі працюють на своїх оригінальних платформах через 8-10 років.

Чи частіше, ніж заміняти ORM, ви хочете знати, що я бачив більше? Видалення ORM повністю, щоб перейти до SQL через проблеми з продуктивністю. Тож незалежно від того, що в цьому випадку ви будете переписувати.

Що стосується реалізації агностика, то це міф. Це дійсно означає скидання вниз. Тож мій підхід полягає в охопленні рівня даних. Зробіть це першокласною частиною вашої мови та дизайну. Це робить для щасливіших, успішніших проектів.


3
Погодьтесь, це також є основою більшості проблем, які я маю із Hibernate взагалі - це компрометує SQL, який він генерує, щоб полегшити заміну бази даних. Він також "робить доступ", припускаючи, що це найкраще місце для зберігання кешового столу, що є рідко випадком ІМО. У Hibernate є випадки падіння модулів настройки SQL, які перетворюють HQL в Oracle, MySQL, SQL Server і т.д. оптимізують SQL і перестають робити дурні речі, які RDBMS робить краще.
mcottle

5

чи варто це?
Це повністю залежатиме від програми.
Якщо ви пишете внутрішню заявку для однієї компанії, забудьте про це. Ця база даних переживе додаток за роками, можливо, десятиліттями.
Якщо, звичайно, вам з самого початку було зрозуміло, що в найближчому майбутньому база даних планується замінити чимось іншим.
Якщо ви пишете це для продажу клієнтам, які можуть мати різні двигуни бази даних, І вимоги такі, що він повинен підтримувати декілька двигунів бази даних, ТОМУ це має сенс.

Тоді для більшості людей, які пишуть програми Java, це значною мірою не має значення.


+1 для згадування програм, де підтримка декількох СУБД є функцією. Якщо ви пропонуєте свою заявку на "самостійний хостинг" (те, що багато клієнтів підприємства вважають бажаним), можливо, це знадобиться. Однак, ймовірно, ви все одно можете дотримуватися одного ORM.
sleske

4

З мого досвіду: ні, це не варто цього у випадку JPA / Hibernate.

Чи варто "програмування на інтерфейс", якщо мова йде про такі речі, як JPA?

Це, але конкретно не має нічого спільного з JPA. Ви можете зайнятися "програмуванням на інтерфейси" Hibernate. Йдеться не про приховування рамки під стандарт, а про SOLID .

Ви коли-небудь фактично поміняли всю продукцію ORM у продукт?

Так і ні. Один із продуктів нашої компанії частково мігрував із сплячого до jOOQ (що не має нічого спільного з JPA). Це був не зовсім "типовий проект для підприємств", про який згадував @codenheim, тому можливість заміни була можливою.

Я не бачу сенсу міняти сплячку на іншу OR-сумісну ORM.

Чи вам колись вдалося повністю уникнути абстрагування чогось подібного до протікання JPA?

Ні. Це неможливо, оскільки і JPA, і сплячка дуже складні. І ви все одно маєте справу з питаннями продуктивності та дизайну Hibernate.


3

Загрожуючи звучати протилежним тут, я б сказав, що так, воно того варте. І це не так.

Проблема полягає не в тому, щоб переключити ORM або постачальника баз даних як такого. Це скоріше питання роз'єднання проблем та збереження рухливості.

Як тільки ви почнете покладатися на деякі деталі реалізації бібліотеки, ви починаєте створювати все глибші та глибші проблеми.

Якщо ви знаєте, що ваша реалізація ORM перебуває в сплячому режимі, ці знання починають простежувати всю архітектуру вашої програми. І кожного разу, коли з'являється нова технологія, яка витісняє сплячку або JPA так ретельно, як це робила сплячка до того, що сталося до неї, ви виявите, що залежності стали набагато глибшими, ніж ви очікували.

Набагато краще відвернути всю турботу про збереження вашої моделі десь із шляху, де всі тонкощі роботи з базами даних та трансакціями та інше можна легко ігнорувати рештою програми. У цьому віддаленому темному кутку ви можете зав'язати себе у вузлах над конкретними деталями реалізації, якщо цього хочете - це вже не має значення.


1

Проблема з агностицизмом впровадження полягає в тому, що ви, будучи розробником, витрачаєте час в будь-якому випадку.

Я написав кілька проектів, які ми витратили багато часу на запис в інтерфейс, які тоді ніколи не використовувались по-новому, ніколи не конвертувались та використовувались так, як є роками

Я також витрачав масу часу програмного забезпечення для перетворення часу, яке ніхто не сподівався потребувати перетворення.

Єдине справжнє спостереження, яке я маю зробити, - це те, що колишнє набагато менш болісне.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.