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

Question

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

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

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

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

---

Немного фона:

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

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

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

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

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

Answer 1

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

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

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

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

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

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