Hibernate in Action
После "iBATIS in Action" подумал что будет нехорошо обойти стороной и "Hibernate in Action". Все таки название Hibernate появилось на моем горизонте несколько раньше чем iBATIS. И пусть этот труд и датирован 2005 годом, его все-таки стоит посмотреть... Как оказалось здесь есть немного по теории ORM
А вот и практически самое начало - ввод в проблему ...
"постоянство" это проблема котороя уже разрешена реляционной технологией и расширениями, такими как хранимые процедуры, или это более глубокая проблема, которая должна быть адресована специальной компонентной модели Java, такой как EJB? Должны мы вручную кодировать каждую примитивную CRUD операцию в SQL и JDBC, или эта работа должна быть автоматизирована? Как мы добьемся переносимости, если каждая СУБД имеет свой SQL диалект? Должны мы оставить SQL полностью и адаптироваться к новой технологии БД, такой как объектная БД? Дебаты продолжаются, но недавно решением было названо ORM и популярность его растет.
...
Приложение с моделью домена не работают напрямую с табличным представлением бизнес сущностей; приложения имею свою собственную объектно-ориентированную модель бизнес сущностей.
Вместо прямой работы со строками и столбцами результирующего набора SQL, бизнес логика взаимодействует с этой объектно-ориентированной моделью домена и ее рантайм реализацией как с графом взаимосвязанных объектов. Бизнес логика никогда не выполняется в БД (как хранимая процедура), она реализуется на Java. Это позволяет бизнес логике использовать естественные объектно-ориентированные концепции, такие как наследование и полиморфизм. В качестве примера, мы могли бы использовать хорошо известные паттерны проектирования, такие как Strategy, Mediator, and Composite [GOF 1995], каждая из которых зависит от полиморфного вызова методов. Теперь предостережение: не все Java приложения спроектированы таким образом, и они не должны. Простые приложения могли бы быть много лучше без модели домена. SQL и JDBC API вполне пригодны для действий с чистыми табличными данными, и новый JDBC RowSet (Sun JCP, JSR 114) делает CRUD (create, read, update, delete) очень легкими. Работая с табличным представлением данных прямо и хорошо понимаемое.
Однако в случае приложений с нетривиальной бизнес-логикой, модель домена помогает значительно улучшить повторное использование кода и его обслуживание.
Если мы снова взглянем на реляционные БД, мы в итоге наблюдаем несоответствие между двумя парадигмами.
SQL операции, такие как отображение и соединение всегда имеют результатом табличное представление. Это полностью отлично от графа взаимосвязанных объектов используемых для выполнения бизнес логики в Java приложениях. Это фундаментально различные модели, а не просто различные способы визуализации одной и той же модели.
...
далее идет несколько надуманный пример - пользователи и счета и проблема как реализовать адреса ... о том как хорошо иметь user-defined column types (UDT) и что не все СУБД его поддерживают ...
далее идет обсуждение проблемы подтипов ... проблема представления связей ... навигации по объектному графу ... и стоимости этих несоответствий
по наблюдениям авторов 30% кода java уходит на преодоление этих несоответствий ..
главная стоимость в области моделирования - обе модели работают с теми же самыми бизнес сущностями, но сильно отличаются...
потом плавный переход к архитектуре со слоем постоянного хранения, и мысли о ручном кодировании DAO классов в которое могут закрадываться человеческие ошибки и поэтому это нужно отдать ORM ... в общем вплотную подходит к вопросу....
ORM это автоатизированное постоянное хранение объектов Java приложений в таблицах реляционных БД, с использованием метаданных которые описывают соответствие между объектами и БД. Работает по трансформации данных их одного представления в другое...
ORM решение состоит из следующих элементов :
- API для выполнения базовых CRUD операций над объектами классов постоянного хранения
- язык или API для спецификации запросов которые ссылаются на классы и свойства классов
- возможности для спецификации метаданных соотвествия
- техника для ORM реализации взаимодействия с транзакциями для выполнения dirty checking, lazy association fetching, and other optimization functions
Mark Fussel [Fussel 1997], исследовал область ORM и определил следующие четыре уровня ORM качества
Pure relational
Чисто реляционная модель вокруг SQL операций. Хороший подход для простых приложений с низким количеством повторно используемого кода. Часто используются хранимые процедуры, убирая работу с бизнес уровня в БД
Light object mapping
Сущности представлены как классы, но вручную делается соответствие классов к таблицам. Довольно распространенных и успешный подход для приложений с малым количеством сущностей, или приложений основанных на метаданных моделей данных.
Medium object mapping
Приложения проектируются вокруг объектной модели. SQL генерируется во время построения системы с использованием инструментов генерации кода или в рантайм самим фреймворком. Запросы могут использвать ОО язык запросов. Объекты кэшируются слоем постоянного хранения. Хорошо работает для приложений среднего размера со сложными транзакциями, и где важна поддержка различных СУБД. Эти прложения не используют хранимых процедур.
Full object mapping
Поддерживает естественное объектное мделирование: composition, inheritance, polymorphisms, and “persistence by reachability.” Прозрачное хранение; persistent классы не наследуются от какого либо специального базового класса и не должны реализовывать специальных интерфейсов. Efficient fetching strategies (lazy and eager fetching) and caching strategies are implemented transparently to the application.
Эта книга (и естественно подразумевается именно Hibernate) как раз о последнем методе.
В итоге ORM это продуктивность, сопровождаемость, производительность, независимость от вендора