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

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

У вас есть фавориты? Есть ли кто-нибудь, с кем вы бы посоветовали остаться в стороне?

ОТВЕТЫ

Ответ 1

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

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

Поэтому рассмотрим только использование пакета JDBC.

Ответ 2

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

Ответ 3

Многие 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))))));

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

У меня был действительно хороший опыт работы с 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();

Ответ 8

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

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

Но в отличие от Hibernate, SimpleORM использует очень простая структура объектов и архитектуры, которая позволяет избежать необходимости комплексный парсинг, обработка байтового кода и т.д. SimpleORM мала и прозрачный, упакованный в две банки всего 79K и 52K в размере, только одна небольшая и необязательная зависимость (SLF4J). (Hibernate - более 2400K плюс около 2000K зависимых банок.) Это упрощает SimpleORM понимают и так сильно уменьшают технический риск.

Ответ 9

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

Oh и Eclipse Link выбраны как эталонная реализация для JPA 2.0

Ответ 10

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

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