Убедитесь, что вы оцениваете реализацию JDO в DataNucleus. Мы начали с Hibernate, потому что он казался очень популярным, но довольно скоро поняли, что это не 100% прозрачное решение для сохранения состояния. Слишком много предостережений, и документация полна слов «если у вас такая ситуация, вы должны писать свой код вот так», что лишает нас удовольствия от свободного моделирования и кодирования, как мы того хотим. JDO никогда не заставлял меня корректировать мой код или модель, чтобы заставить их "работать должным образом". Я могу просто проектировать и кодировать простые POJO, как если бы я собирался использовать их только «в памяти», но я могу сохранять их прозрачно.
Другое преимущество JDO / DataNucleus по сравнению со спящим режимом заключается в том, что он не имеет всех накладных расходов на отражение во время выполнения и более эффективен с точки зрения памяти, поскольку использует улучшение байтового кода времени сборки (возможно, добавьте 1 секунду к времени сборки для большого проекта), а чем шаблон прокси с отражением во время выполнения hibernate.
Еще одна вещь, которая может вас раздражать в Hibernate, - это то, что у вас есть ссылка на то, что, по вашему мнению, является объектом ... это часто «прокси» для объекта. Без преимущества улучшения байт-кода требуется шаблон прокси, чтобы разрешить загрузку по запросу (т. Е. Избежать затягивания всего графа объекта, когда вы втягиваете объект верхнего уровня). Будьте готовы переопределить equals и hashcode, потому что объект, на который, по вашему мнению, вы ссылаетесь, часто является просто прокси для этого объекта.
Вот пример разочарования, которое вы получите с Hibernate, чего не получите с JDO:
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
Если вам нравится кодировать «обходные пути», тогда, конечно, Hibernate для вас. Если вам нравится чистая, объектно-ориентированная разработка на основе моделей, при которой вы тратите все свое время на моделирование, проектирование и кодирование, а не на уродливые обходные пути, тогда потратьте несколько часов на оценку JDO / DataNucleus. Затраченные часы окупятся в тысячу раз.
Обновление, февраль 2017 г.
В течение некоторого времени DataNucleus реализует стандарт сохраняемости JPA в дополнение к стандарту сохраняемости JDO, поэтому перенос существующих проектов JPA из Hibernate в DataNucleus должен быть очень простым, и вы можете получить все вышеупомянутые преимущества DataNucleus с очень небольшим изменением кода. , если есть. Итак, с точки зрения вопроса, выбор конкретного стандарта, JPA (только RDBMS) против JDO (RDBMS + No SQL + ODBMSes + другие), DataNucleus поддерживает оба, Hibernate ограничен только JPA.
Производительность обновлений Hibernate DB
Еще одна проблема, которую следует учитывать при выборе ORM, - это эффективность его механизма грязной проверки, что становится очень важным, когда ему нужно создать SQL для обновления объектов, которые изменились в текущей транзакции, особенно когда объектов много. В этом SO-ответе есть подробное техническое описание механизма грязной проверки Hibernate: JPA со вставкой HIBERNATE очень медленно
person
Volksman
schedule
11.03.2010
