О Java ORM — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
Строка 8: Строка 8:
 
Минусы:
 
Минусы:
 
* Немного монструозны (перегружены функционалом).
 
* Немного монструозны (перегружены функционалом).
* Возможно, не вполне идеальна логика отображения — конструирование объекта всегда связано с десериализацией , для сохранения ID связанных объектов без самих объектов применяются proxy-классы и ленивая подгрузка (нет возможности одно и то же поле, скажем, person_id, видеть и в виде ID, и в виде объекта)…
+
* Возможно, не вполне идеальна логика отображения — конструирование объекта всегда связано с десериализацией, для сохранения ID связанных объектов без самих объектов применяются proxy-классы и ленивая подгрузка (нет возможности одно и то же поле, скажем, person_id, видеть и в виде ID, и в виде объекта)…
 
* HQL/JPQL — всё-таки недоразумение. Не могу понять смысл реализации собственного строкового языка запросов — SQL если уж во что-то заворачивать, то во что-то объектно-структурированное — хотя бы в объект типа «запрос» с полями tables, where, order by, group by и т. п., но не снова в строковой же литерал!
 
* HQL/JPQL — всё-таки недоразумение. Не могу понять смысл реализации собственного строкового языка запросов — SQL если уж во что-то заворачивать, то во что-то объектно-структурированное — хотя бы в объект типа «запрос» с полями tables, where, order by, group by и т. п., но не снова в строковой же литерал!
 
* Объекты запросов есть в виде Criteria, но они не очень удобны, ибо многословны.
 
* Объекты запросов есть в виде Criteria, но они не очень удобны, ибо многословны.
Строка 41: Строка 41:
 
Минусы:
 
Минусы:
 
* Серьёзные минусы вроде отсутствуют, разве что логика отображения та же, что в JPA
 
* Серьёзные минусы вроде отсутствуют, разве что логика отображения та же, что в JPA
 +
 +
== Идея ==
 +
 +
* 1 часть — объект «соединение». Умеет делать запросы в синтаксически кратком стиле (возможно, Fluent API) и возвращать записи в виде чего-то типа Map<String,String> или Map<String,Object>. Кроме того, является аналогом сессии/persistence manager’а для моделей.
 +
* 2 часть — базовый класс модели. Запись БД хранит в виде такого же объекта Map, никуда не вытаскивает. Создание модели = вызов конструктора, который только сохраняет к себе этот Map.

Версия 12:56, 17 февраля 2016

JPA: Hibernate, EclipseLink

Плюсы:

  • Умеют дохрена всего :)
  • В Hibernate есть Envers, из коробки умеющий логгировать историю изменений сущностей в отдельные таблицы
  • Для получения красивого Fluent API запросов вместо HQL/JPQL-литералов можно подключить Querydsl

Минусы:

  • Немного монструозны (перегружены функционалом).
  • Возможно, не вполне идеальна логика отображения — конструирование объекта всегда связано с десериализацией, для сохранения ID связанных объектов без самих объектов применяются proxy-классы и ленивая подгрузка (нет возможности одно и то же поле, скажем, person_id, видеть и в виде ID, и в виде объекта)…
  • HQL/JPQL — всё-таки недоразумение. Не могу понять смысл реализации собственного строкового языка запросов — SQL если уж во что-то заворачивать, то во что-то объектно-структурированное — хотя бы в объект типа «запрос» с полями tables, where, order by, group by и т. п., но не снова в строковой же литерал!
  • Объекты запросов есть в виде Criteria, но они не очень удобны, ибо многословны.

ActiveJPA

Реализация Active Record поверх JPA.

ActiveJDBC

Плюсы:

  • Active Record для Java
  • Легковесный:
    • Необязательны геттеры/сеттеры, поля можно читать по именам model.get("поле")
    • Нет ни проксей, ни сессий, ни persistence manager’ов, ни DAO, ни репозиториев, ни «attach/detach», ни собственного языка запросов

Минусы:

  • Неотключаемое автоматическое определение таблиц и типов полей во время выполнения. Также есть автоматическая привязка классов к таблицам по правилам английского языка — извращение, но по крайней мере отключаемое.
  • Отсутствие поддержки нескольких схем (#144).
  • Трудно во время выполнения явно указать соединение БД, с которым должна работать конкретная модель — несколько соединений указывается только на уровне аннотаций во время компиляции, а в рантайме всегда используется текущее «привязанное» к имени соединение.
  • Отсутствие доступа к «старым» («чистым») значениям полей при сохранении модели.
  • Отсутствие поддержки композитных первичных ключей — всегда нужна автоинкрементная колонка «id», даже в таблицах отношений «многие ко многим»

Ebean ORM

По большей части похож на JPA, те же яйца, только в профиль. Классы размечаются ровно теми же JPA-аннотациями… EbeanServer — тот же аналог сессии или persistence manager’а… других частей JPA, правда, нет.

Плюсы:

  • Наличие Fluent API запросов, отсутствие велосипедных языков типа JPQL
  • Встроенная поддержка сериализации/десериализации JSON

Минусы:

  • Серьёзные минусы вроде отсутствуют, разве что логика отображения та же, что в JPA

Идея

  • 1 часть — объект «соединение». Умеет делать запросы в синтаксически кратком стиле (возможно, Fluent API) и возвращать записи в виде чего-то типа Map<String,String> или Map<String,Object>. Кроме того, является аналогом сессии/persistence manager’а для моделей.
  • 2 часть — базовый класс модели. Запись БД хранит в виде такого же объекта Map, никуда не вытаскивает. Создание модели = вызов конструктора, который только сохраняет к себе этот Map.