Когда вы можете/должны полностью использовать подход ORM?

Question

Мне кажется, что введение инструмента ORM должно сделать вашу архитектуру чище, но для повышения эффективности я обходил его и время от времени перебирал набор результатов JDBC.Это приводит к нескоординированному клубку артефактов вместо более чистой архитектуры.

Это потому, что я применяю инструмент в неверном контексте, или дело в чем-то более глубоком?

Когда вы можете/должны полностью использовать подход ORM?

Любая информация будет принята с благодарностью.

---

Немного предыстории:

В моей среде имеется около 50 клиентских компьютеров и 1 достаточно мощный SQL-сервер.

У меня есть настольное приложение, в котором все 50 клиентов постоянно имеют доступ к данным.

Модель данных проекта претерпела ряд реорганизаций по разным причинам, включая ясность, эффективность и т. д.

История моей модели данных

1. JDBC вызывает напрямую
2. DAO + POJO без связей между Pojo (по сути, оболочка JDBC).
3. Добавлены связи между POJO, реализующими отложенную загрузку, но просто скрывающие вызовы между DAO.
4. Перешел на Hibernate, увидев, насколько «простым» он сделал доступ к данным (он сделал отношения между POJO тривиальными) и потому, что это могло уменьшить количество обращений к базе данных при работе со многими связанными объектами.
5. Поскольку это было настольное приложение, держать сеансы открытыми в течение длительного времени было кошмаром, поэтому в конечном итоге это вызвало множество проблем.
6. Вернулся к частичному подходу DAO/Hibernate, который позволяет мне выполнять прямые вызовы JDBC за кулисами DAO, одновременно используя Hibernate.

Answer 1

Спящий режим имеет больше смысла, когда ваше приложение работает графы объектов, которые сохраняются в СУБД.Вместо этого, если логика вашего приложения работает с двумерной матрицей данных, извлечение их через прямой JDBC работает лучше.Хотя Hibernate написан поверх JDBC, у него есть возможности, которые может быть непросто реализовать в JDBC.Например:

1. Скажем, пользователь просматривает строку в пользовательском интерфейсе и меняет некоторые значения, а вы хотите запустить запрос на обновление только для тех столбцов, которые действительно изменились.
2. Чтобы избежать тупиковых ситуаций, вам необходимо поддерживать глобальный порядок SQL-запросов в транзакции.Сделать это правильно JDBC может быть непросто
3. Легко настроить оптимистическую блокировку.Когда вы используете JDBC, вам необходимо помнить об этом в каждом запросе на обновление.
4. Пакетные обновления, ленивая материализация коллекций и т. д. также могут быть нетривиальными для реализации в JDBC.

(Я говорю "мощь быть нетривиальным", потому что это, конечно, можно сделать - и вы можете быть суперхакером :)

Hibernate также позволяет вам запускать собственные SQL-запросы, если вам это необходимо.

Надеюсь, это поможет вам принять решение.

ПС:Сохранение сеанса открытым на клиенте удаленного рабочего стола и возникновение проблем на самом деле не является проблемой Hibernate — вы столкнетесь с той же проблемой, если будете держать соединение с БД открытым в течение длительного времени.