Який Java ORM ви віддаєте перевагу і чому? [зачинено]

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

У вас є якісь фаворити? Чи є якісь рекомендації, щоб ви не трималися осторонь?

Я перестав використовувати ORM.

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

Тому подумайте просто про використання пакету JDBC.

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

Багато ORM чудові, ви повинні знати, чому ви хочете додати абстракцію поверх JDBC. Я можу порекомендувати вам http://www.jooq.org (відмова від відповідальності: я творець jOOQ, тому ця відповідь упереджена). jOOQ містить таку парадигму:

• SQL - хороша річ. Багато речей можна досить добре виразити в SQL. Немає необхідності в повній абстракції SQL.
• Модель реляційних даних - хороша річ. Це доведена найкраща модель даних за останні 40 років. Немає потреби в базах даних XML або справді об'єктно-орієнтованих моделей даних. Натомість ваша компанія запускає кілька примірників Oracle, MySQL, MSSQL, DB2 або будь-яких інших RDBMS.
• SQL має структуру та синтаксис. Вона не повинна виражатися за допомогою конкатенації рядків "низького рівня" в JDBC - або "високого рівня" String конкатенації в HQL - обидві вони схильні приймати синтаксичні помилки.
• Змінна прив'язка має тенденцію бути дуже складною для вирішення основних запитів. ТО - це те, що слід абстрагувати.
• POJO відмінно під час написання коду Java, маніпулювання даними бази даних.
• POJO - це біль писати та підтримувати вручну. Генерація коду - це шлях. Ви матимете безпечні для компіляції запити, включаючи безпеку типу даних.
• База даних виходить першою. Хоча додаток, що знаходиться поверх вашої бази даних, може змінюватися з часом, сама база даних, ймовірно, триватиме довше.
• Так, у вас є збережені процедури та визначені користувачем типи (UDT) у вашій застарілій базі даних. Ваш інструмент бази даних повинен це підтримувати.

Є багато інших хороших ОРМ. Особливо сплячий або iBATIS мають велике співтовариство. Але якщо ви шукаєте інтуїтивно зрозумілий, простий, я скажу, спробуйте jOOQ. Вам сподобається! :-)

Перевірте цей приклад SQL:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

І як це можна виразити в jOOQ:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

Впадає в сплячку, оскільки це в основному стандарт дефакто на Яві і був однією з рушійних сил у створенні JPA. Він отримує чудову підтримку навесні, і майже кожен Java-сервіс підтримує його. Нарешті, GORM - це дійсно крута обгортка навколо неї, яка робить динамічні шукачі тощо, використовуючи Groovy.

Його навіть перенесли в .NET (NHibernate), щоб ви могли використовувати його і там.

Зимує, тому що:

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

Кілька пунктів про те, чому (і коли) використовувати ORM:

• ви працюєте з об’єктами у вашій системі (якщо ваша система добре розроблена). Навіть якщо ви користуєтеся JDBC, ви в кінцевому підсумку зробите деякий шар перекладу, щоб ви перенесли свої дані вашим об'єктам. Але я думаю, що сплячий режим краще перекладати, ніж будь-яке рішення на замовлення.
• це не позбавляє вас контролю. Ви можете керувати речами дуже дрібними деталями, а якщо в API немає певної віддаленої функції - виконайте власний запит, і він у вас є.
• будь-яка система середнього або більшого розміру не може дозволити собі одну тону запитів (будь то в одному місці або розкидана по всьому), якщо вона спрямована на підтримку
• якщо продуктивність не є критичною. Hibernate додає накладні результати, які в деяких випадках не можна ігнорувати.

Я рекомендую використовувати MyBatis . Це тонкий шар на вершині JDBC, дуже просто зіставити об’єкти в таблиці і все ще використовувати звичайний SQL, все під вашим контролем.

Я мав по-справжньому хороший досвід роботи з Avaje Ebean, коли я писав заявку JavaSE середнього розміру.

Він використовує стандартні анотації JPA для визначення об'єктів, але відкриває набагато простіший API (No EntityManager або будь-яке з цього прикріпленого / відокремленого об'єкта лайно). Він також дозволяє легко використовувати запити SQL або звичайні дзвінки JDBC про події, коли це необхідно.

Він також має дуже приємний для живлення та безпечний тип API для запитів. Ви можете писати такі речі, як:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

SimpleORM , тому що це прямо і не магічно. Він визначає всі метадані структури даних у коді Java і є дуже гнучким.

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

Але на відміну від Hibernate, SimpleORM використовує дуже просту структуру об'єктів та архітектуру, що дозволяє уникнути необхідності складного розбору, обробки байтового коду і т.д. залежність (Slf4j). (Зимова сплячка становить понад 2400 КК та близько 2000 КЗ залежних банок.) Це робить SimpleORM легким для розуміння та значно зменшує технічний ризик.

Eclipse Link , з багатьох причин, але помітно, я відчуваю, що в ньому менше набряку, ніж у інших основних потокових рішень (принаймні, менше у вас в обличчі).

Oh та Eclipse Link були обрані для опорної реалізації для JPA 2.0

Хоча я поділяю занепокоєння щодо заміни Java для запитів у форматі SQL у вільній формі, я дійсно думаю, що люди, що критикують ORM, роблять це через загально поганий дизайн додатків.

True OOD керується класами та відносинами, і ORM дає вам послідовне відображення різних типів відносин та об'єктів. Якщо ви використовуєте інструмент ORM і в кінцевому підсумку кодуєте вирази запитів будь-якою мовою запиту, яку підтримує рамка ORM (включаючи, але не обмежуючись ними, дерева виразів Java, методи запитів, OQL тощо), ви, безумовно, робите щось не так, тобто модель вашого класу швидше за все, не підтримує ваші вимоги так, як слід. Чистий дизайн програми насправді не потребує запитів на рівні програми. Я рефакторинг багатьох проектів, коли люди почали використовувати рамку ORM так само, як і їх використовували для вбудовування струнних констант SQL у свій код, і врешті-решт, всі здивувались тому, наскільки просто та ремонтоване отримує вся програма, коли ви співпадаєте доповнити модель класу за допомогою моделі використання. Зрозуміло, для таких речей, як функціональність пошуку тощо, вам потрібна мова запитів, але навіть тоді запити настільки обмежені, що створювати навіть складний перегляд та відображення, що для стійкого класу, що читається лише набагато приємніше підтримувати та переглядати, ніж будувати вирази якоюсь мовою запитів у коді вашої програми. Підхід VIEW також використовує можливості бази даних і завдяки матеріалізації може бути набагато кращим за продуктивність, ніж будь-який написаний вручну SQL у вашому джерелі Java. Отже, я не бачу жодної причини для нетривіальної програми НЕ використовувати ORM. але навіть тоді запити настільки обмежені, що створювати навіть складний VIEW та відображати, що для стійкого класу, який є лише для читання, набагато приємніше підтримувати та переглядати, ніж будувати вирази на якійсь мові запитів у коді вашої програми. Підхід VIEW також використовує можливості бази даних і завдяки матеріалізації може бути набагато кращим за продуктивність, ніж будь-який написаний вручну SQL у вашому джерелі Java. Отже, я не бачу жодної причини для нетривіальної програми НЕ використовувати ORM. але навіть тоді запити настільки обмежені, що створювати навіть складний VIEW та відображати, що для стійкого класу, який є лише для читання, набагато приємніше підтримувати та переглядати, ніж будувати вирази на якійсь мові запитів у коді вашої програми. Підхід VIEW також використовує можливості бази даних і завдяки матеріалізації може бути набагато кращим за продуктивність, ніж будь-який написаний вручну SQL у вашому джерелі Java. Отже, я не бачу жодної причини для нетривіальної програми НЕ використовувати ORM.