Какую Java ORM вы предпочитаете и почему?

Hibernate, потому что он фактически является стандартом Java и был одной из движущих сил при создании JPA. У него отличная поддержка в Spring, и почти каждая среда Java поддерживает его. Наконец, GORM - это действительно классная оболочка для выполнения динамических поисковиков и т. д. С использованием Groovy.

Он даже был перенесен на .NET (NHibernate), так что вы можете использовать его и там.

SimpleORM, потому что это прямолинейно и без магии. Он определяет все структуры метаданных в Java-коде и очень гибок.

SimpleORM provides similar functionality to Hibernate by mapping data in a relational database to Java objects in memory. Queries can be specified in terms of Java objects, object identity is aligned with database keys, relationships between objects are maintained and modified objects are automatically flushed to the database with optimistic locks.

But unlike Hibernate, SimpleORM uses a very simple object structure and architecture that avoids the need for complex parsing, byte code processing etc. SimpleORM is small and transparent, packaged in two jars of just 79K and 52K in size, with only one small and optional dependency (Slf4j). (Hibernate is over 2400K plus about 2000K of dependent Jars.) This makes SimpleORM easy to understand and so greatly reduces technical risk.

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

О, и Eclipse Link был выбран в качестве эталонной реализации для JPA 2.0.

Я перестал использовать ORM.

Причина не в большом недостатке концепции. Hibernate работает хорошо. Вместо этого я обнаружил, что запросы имеют низкие накладные расходы, и я могу уместить много сложной логики в большие запросы SQL и перенести большую часть своей обработки в базу данных.

Так что рассмотрите возможность использования пакета JDBC.

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

У меня был действительно хороший опыт работы с Авахе Эбеан, когда я писал приложение JavaSE среднего размера.

Он использует стандартные аннотации JPA для определения сущностей, но предоставляет гораздо более простой API (без EntityManager или какой-либо из этих прикрепленных / отсоединенных сущностей). Он также позволяет при необходимости легко использовать SQL-запросы или обычные вызовы JDBC.

Он также имеет очень приятный гибкий и безопасный по типу API для запросов. Вы можете написать что-то вроде:

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

Спящий режим, потому что это:

• стабильна - существует столько лет, что у нее нет серьезных проблем
• диктует стандарты в области ORM
• реализует стандарт (JPA), помимо того, что диктует его.
• есть масса информации об этом в Интернете. Есть много руководств, решений общих проблем и т. д.
• мощно - вы можете преобразовать очень сложную объектную модель в реляционную модель.
• он поддерживает любые основные и средние СУБД
• легко работать, как только ты выучишь это хорошо

Несколько моментов о том, почему (и когда) использовать ORM:

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

Я бы рекомендовал использовать MyBatis. Это тонкий слой поверх JDBC, очень легко сопоставить объекты с таблицами и при этом использовать простой SQL, все под вашим контролем.

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

• SQL - это хорошо. Многие вещи можно довольно красиво выразить в SQL. Нет необходимости в полной абстракции SQL.
• Реляционная модель данных - это хорошо. Это лучшая модель данных за последние 40 лет. Нет необходимости в базах данных XML или действительно объектно-ориентированных моделях данных. Вместо этого ваша компания использует несколько экземпляров Oracle, MySQL, MSSQL, DB2 или любых других СУБД.
• SQL имеет структуру и синтаксис. Его не следует выражать с помощью конкатенации строк «низкого уровня» в JDBC или «конкатенации строк высокого уровня в HQL» - оба из которых склонны содержать синтаксические ошибки.
• Привязка переменных может быть очень сложной при работе с основными запросами. ЭТО нужно абстрагироваться.
• POJO отлично подходят для написания кода Java, управляющего данными базы данных.
• POJO сложно писать и поддерживать вручную. Генерация кода - это лучший способ. У вас будут безопасные для компиляции запросы, включая безопасность типов данных.
• База данных на первом месте. Хотя приложение поверх вашей базы данных может со временем измениться, сама база данных, вероятно, прослужит дольше.
• Да, у вас есть хранимые процедуры и пользовательские типы (UDT) в вашей устаревшей базе данных. Ваш инструмент базы данных должен это поддерживать.

Есть много других хороших ORM. Особенно у Hibernate или 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))))));

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

Истинный OOD управляется классами и отношениями, а ORM дает вам согласованное сопоставление различных типов отношений и объектов. Если вы используете инструмент ORM и в конечном итоге кодируете выражения запроса на любом языке запросов, поддерживаемом инфраструктурой ORM (включая, помимо прочего, деревья выражений Java, методы запросов, OQL и т. д.), Вы определенно делаете что-то неправильно, то есть ваша модель класса скорее всего, не поддерживает ваши требования так, как должно. Чистый дизайн приложения на самом деле не требует запросов на уровне приложения. Я проводил рефакторинг многих проектов, которые люди начинали с использования ORM-фреймворка, точно так же, как они использовались для встраивания строковых констант SQL в свой код, и в конце концов все были удивлены тем, насколько простым и удобным в обслуживании становится все приложение, когда вы подходите. улучшите модель вашего класса с помощью модели использования. Конечно, для таких вещей, как функции поиска и т. д. Вам нужен язык запросов, но даже в этом случае запросы настолько ограничены, что создание даже сложного VIEW и сопоставление его с постоянным классом только для чтения намного удобнее поддерживать и смотреть, чем создавать выражения на каком-то языке запросов в коде вашего приложения. Подход VIEW также использует возможности базы данных и, благодаря материализации, может быть намного лучше с точки зрения производительности, чем любой написанный вручную SQL в вашем исходном коде Java. Итак, я не вижу причин, по которым нетривиальное приложение НЕ использует ORM.