Ловушки и практические примеры использования: Toplink, Hibernate, Eclipse Link, Ibatis

Question

Я много работал с Hibernate в качестве моей реализации JPA. В большинстве случаев это нормально! Но я также видел много подводных камней:

• Удаленный доступ с сохраненными объектами затруднен, потому что Hibernate заменяет коллекции Java своей собственной реализацией коллекции. Поэтому каждый клиент должен иметь библиотеки Hibernate .jar. Вы должны заботиться об исключениях LazyLoading и т. Д. Один из способов обойти эту проблему - использование веб-сервисов.
• Грязная проверка выполняется с использованием базы данных без блокировки.
• «Задержка SQL», приводит к тому, что доступ к данным не соответствует требованиям ACID. (Утерянные данные ...)
• Имплицированные обновления >> Так что мы не знаем, был ли объект изменен или нет (фиксация вызывает обновления).

Есть ли аналогичные проблемы с Toplink, Eclipse Link и Ibatis? Когда я должен их использовать? Есть ли у них аналогичная производительность? Есть ли причины выбрать Eclipse Link/Toplink ... over Hibernate?

Answer 1

Я могу поделиться своим изрядным количеством Hibernate ловушек:

• Критерии API не типизированным
• Критерии API относительно плохо разработан (например, вы не можете получить текущие алиасы)
• Если вы создаете псевдоним, вы заставляете внутреннее соединение (это в документации, но вводит в заблуждение)
• Нет поддержки Союзов
• не легкий путь, чтобы «де-прокси» упорной объект (Remoting поддерживается третьими лицами)
• нет поддержку для таблиц без первичных ключей (я теперь это не глупо, но это происходит в старых схемах)
• нет простой способ (не очень тупые)

Что касается большинства реализаций JPA, я всегда обнаружил, что мне придется полагаться на некоторые пользовательские аннотации или так делать вещи, которые не покрываются спецификацией JPA.

Answer 2

Не может комментировать другие реализации, но и для DataNucleus AccessPlatform ...

1. Remoting может потребовать «jdo.jar» присутствовать, так как классы модели являются байткодом увеличено. В качестве альтернативы, если используется «только для чтения» на удаленной стороне, тогда используйте не-расширенные классы, и все работает без дополнительной банки.
2. Грязная проверка выполняется путем улучшения байт-кода, поэтому не нужно идти в хранилище данных, чтобы узнать, загрязнено ли поле (и вы можете управлять блокировками, когда хотите перейти в хранилище данных). Очевидно, что это дает значительные преимущества по сравнению с реализацией, основанной на отражении.
3. Я знаю, что «потерянных обновлений» не возможно; использование оптимистической блокировки помогает.
4. Вы можете получить неявные обновления из-за «управляемых отношений» (где у вас двунаправленное отношение, и вы меняете только одну сторону, поэтому DataNucleus обновляет другую сторону, чтобы быть последовательной ... на flush()). Вы можете отключить «управляемые отношения» (до точки). Вы можете легко включить управление версиями объектов и узнать, изменен ли объект или нет.

Причина выбрать DataNucleus является documented here

НТН

--Andy DataNucleus

Answer 3

Есть ли причины для выбора Eclipse Ссылка/Toplink ... через Hibernate?

В O/R карте разработчиков (где я живу;)), это распространенный факт, что Toplink считается наиболее полнофункциональным и лучшим O/R-картером. У этого есть свои недостатки, но его огромное количество функций делает его чем-то, что трудно победить. Поскольку он теперь доступен с открытым исходным кодом и бесплатным, я бы попробовал.

iBatis на самом деле не является сопоставителем O/R, это скорее класс наполнителя/persister через жестко закодированный SQL. Поэтому вам нужно сделать тяжелую работу и написать все вопросы. iBatis полезен, когда вы используете базу данных с сохраненными процессами и должны использовать эти proc для DML/set retrieval.

Answer 4

В отношении Ebean ОРМ http://www.avaje.org и ваших Ловушки:

Remoting

Вы можете использовать режим «ваниль» на запрос, а затем Ebean вернутся простые бобы и коллекции. Это работает только при использовании «динамических прокси/динамических подклассов», но не в том случае, если вы используете Enhancement (поскольку классы entity-компонентов явно улучшены).

Грязная проверка выполняется с использованием базы данных без блокировки.

Я считаю, что вы имеете в виду Оптимистическую параллельную проверку? Если это так, то по определению это делается без явной блокировки БД. Вам нужно использовать Pessimistic Locking, если вы хотите/нуждаетесь в блокировке БД (выберите для обновления и т. Д.), Поэтому я не буду следовать вашей точке там.

Задержка SQL

Ebean не имеет сессий и поэтому он не имеет сеанса флеш(). SQL может по-прежнему задерживаться с Ebean, когда вы используете пакет JDBC, но это не та же самая задержка, которую вы получаете с помощью сеанса flush().

Неявные Обновления

Распространенная жалоба мы слышим от экс-Hibernate и экс-JPA людей. Ebean архивируется без сеанса/entityManager. Вместо этого вам нужно явно сохранить() bean-компонент или использовать этот каскад для связанных bean-компонентов. Так что да, никаких неявных обновлений с Ebean.