Это довольно открытый вопрос. Я начну новый проект и буду искать различные ORM для интеграции с доступом к базе данных.
У вас есть фавориты? Есть ли кто-нибудь, с кем вы бы посоветовали остаться в стороне?
Я прекратил использование ORM.
Причина в этом не является большим недостатком. Спящий режим работает хорошо. Вместо этого я обнаружил, что запросы имеют небольшие накладные расходы, и я могу вместить много сложной логики в большие SQL-запросы и перенести большую часть моей обработки в базу данных.
Поэтому рассмотрим только использование пакета JDBC.
Нет, поскольку наличие ORM требует слишком большого контроля с небольшими преимуществами. Сбережения времени легко сбрасываются, когда вам приходится отлаживать аномалии, связанные с использованием ORM. Кроме того, ORM препятствуют разработчикам изучать SQL и как работают реляционные базы данных и используют их для своей выгоды.
Многие ORM велики, вам нужно знать, почему вы хотите добавить абстракцию поверх JDBC. Я могу рекомендовать http://www.jooq.org вам (отказ от ответственности: я создатель jOOQ, поэтому этот ответ предвзятый). jOOQ охватывает следующую парадигму:
Есть много других хороших 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))))));
Hibernate, потому что это в основном стандарт defacto на Java и был одной из движущих сил в создании JPA. Он получил отличную поддержку в Spring, и почти каждая инфраструктура Java поддерживает его. Наконец, GORM - это действительно крутая обертка вокруг нее, использующая динамические искатели и т.д., Используя Groovy.
Он даже был перенесен в .NET(NHibernate), поэтому вы можете использовать его там тоже.
Спящий режим, потому что он:
Несколько вопросов о том, почему (и когда) использовать ORM:
Я бы рекомендовал использовать 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 предоставляет аналогичные функциональность для Hibernate путем сопоставления данных в реляционной базе данных на Java объектов в памяти. Запросы могут быть указанных в терминах объектов Java, идентичность объекта ключи базы данных, отношения между объекты сохраняются и изменяются объекты автоматически очищаются до база данных с оптимистичными замками.
Но в отличие от Hibernate, SimpleORM использует очень простая структура объектов и архитектуры, которая позволяет избежать необходимости комплексный парсинг, обработка байтового кода и т.д. SimpleORM мала и прозрачный, упакованный в две банки всего 79K и 52K в размере, только одна небольшая и необязательная зависимость (SLF4J). (Hibernate - более 2400K плюс около 2000K зависимых банок.) Это упрощает SimpleORM понимают и так сильно уменьшают технический риск.
Eclipse Link по многим причинам, но особенно я чувствую, что у него меньше раздутий, чем другие решения для основного потока (по крайней мере, меньше в вашем поверхностное раздувание).
Oh и Eclipse Link выбраны как эталонная реализация для JPA 2.0
В то время как я разделяю озабоченность относительно замещения Java для SQL-запросов произвольной формы, я действительно думаю, что люди, критикующие ORM, делают это из-за плохого дизайна приложений.
True OOD управляется классами и отношениями, а ORM дает согласованное сопоставление различных типов отношений и объектов. Если вы используете инструмент ORM и заканчиваете выражения запроса кодирования на любом языке запросов, поддерживаемом картой ORM (включая, но не ограничиваясь ими, деревья выражений Java, методы запросов, OQL и т.д.), Вы определенно делаете что-то неправильно, то есть модель вашего класса скорее всего, не поддерживает ваши требования так, как должно. Чистый дизайн приложения действительно не требует запросов на уровне приложения. Я занимался реорганизацией многих проектов, которые люди запускали с использованием структуры ORM так же, как они были использованы для встраивания строковых констант SQL в свой код, и в конце концов все были удивлены тем, насколько просто и удобно обслуживать все приложение, модель вашего класса с использованием модели использования. Разумеется, для таких вещей, как функция поиска и т.д. Вам нужен язык запросов, но даже тогда запросы настолько ограничены, что создание даже сложного VIEW и сопоставление с постоянным классом только для чтения гораздо приятнее поддерживать и смотреть, чем строить выражения на некотором языке запросов в коде вашего приложения. Подход VIEW также использует возможности базы данных и, благодаря материализации, может быть намного лучше, чем любой написанный вручную SQL в вашем Java-источнике. Итак, я не вижу причин для нетривиального приложения НЕ использовать ORM.