по следам /topic/78511\r
\r
Начнем издалека - откуду пришло, зачем нужно и т.д.\r
\r
\tМногозвенная система, основанная на идеологии “клиент-сервер” – это современное видение общей архитектуры ИС. В зависимости от сложности и требований к задаче количество “звеньев” может меняться, но основа – “клиент-сервер” – обычно существует в той или иной форме практически в любом современном ПО. За время своего существования термин изрядно потрепался – но суть его осталась прежней – а именно: разграничение обязанностей между различными частями системы исходя из соображений эффективности их выполнения этими частями. Сегодня существует достаточно большое количество решений и технологий делающих возможным проектирование и реализацию таких систем. \r
\tСамыми распространенными и востребованными на сегодняшний день являются 2х-звенные системы. В которых архитектура клиент-сервер в своей основе обязательно имеет 2 компонента – один из них это какая-либо СУБД, другой – клиентское приложение, использующее эту СУБД не только как место хранения, но и как место обработки информации. Такое распределение обязанностей оказалось весьма эффективным и достаточным для очень широкого круга задач. Этому в частности способствовало развитие SQL-серверов БД. Так все ведущие поставщики СУБД добавили в свои продукты процедурные расширения языка SQL – что значительно расширило круг решаемых на нем задач. При таком подходе клиенту отводится роль ввода и отображения информации (тонкий клиент) – в то время как вся функциональная составляющая (бизнес логика) программы сосредоточенна на сервере БД (например, в виде хранимых процедур). В общем-то, именно для таких задача (т.е. задач построения пользовательского интерфейса для ввода и отображения информации) и были предназначены DataSets – объекты, моделирующие табличные объекты серверной БД (т.е. таблицы и представления). Именно эти цели они и удовлетворяют. Пройдя достаточно долгий путь развития, сегодня они позволяют сравнительно просто и эффективно создавать сколь угодно сложный интерфейс пользователя. С другой стороны для проектирования серверных компонентов – т.е. компонентов обладающих своим поведением и реализующим какую-то часть бизнес логики системы они (DataSets) не удобны. Так как DataSet моделирует не бизнес-объект системы, а непосредственно низкоуровневый объект БД, что совершенно не соответствует тому, что необходимо для реализации системы спроектированной с использованием ООА и ООП. Т.е. налицо несоответствие между результатами проектирования – т.е. декомпозиция системы на множество классов и возможностями DataSet’ов в смысле реализации этих классов на каком-либо ОО-языке. Ясно, что необходим другой механизм доступа к БД, позволяющий бизнес-объектам сохранять свое состояние в БД. Средства, осуществляющие эту задачу, называют средствами Object Relation Mapping’а (ORM). \r
\r
продолжение следует...

Часть 2


На самом деле информационная система не однородна и представляет набор слоев отвечающих за выполнение определенного круга задач. В частности слой, выполняющий сохранение бизнес-объектов в БД принято называть слоем доступа к данным (DAL). Традиционно задача реализации этой части системы в полном объеме являлась нетривиальной и, обычно, решалась только для частных случаев и для конкретных потребностей системы в целом. Тем не менее, сейчас работы в данном направлении уже привели к ощутимым результатам. Прежде всего, стоит отметить JDO – открытый стандарт на средства ORM в java. Его утверждение послужило толчком к разработке целого ряда открытых и коммерческих продуктов.

В JDO интересно еще и то, что фактически развивается декларативное управление объектами системы подобно тому, как сервер БД управляет объектами БД. Пока еще нельзя сравнивать эффективность алгоритмов СУБД и ORM-средств подобных Hibernate или серверов приложений – но общая тенденция налицо. Hibernate, например, предлагает язык HQL (hibernate query language) – sql-подобный язык где вы оперируете уже не таблицами и столбцами, а объектами и их атрибутами. Вы также как в sql можете задавать критерии объектов, которые должны быть возвращены запросом. При этом hibernate сам выбирает стратегию выполнения запроса. Т.е. возможна автоматическая оптимизация и подбор оптимального плана запроса исходя из различного рода статистических данных, которыми hibernate располагает в силу того, что, работая с hibernate, пользователь описывает только структуру сохраняемых объектов, то весь механизм напоминает механизм работы пользователя с СУБД.
Похожие тенденции просматриваются и среди серверов приложений. Их цель – предоставление среды функционирования различных бизнес-объектов. При этом форма работы отношений объектов с сервером также носит сильно выраженный декларативный характер.
Обычно сервер приложений берет на себя:
- управление жизненным циклом объектов системы.
- управление транзакциями
- безопасность
- стратегию сохранения объектов в каком-либо постоянном хранилище (РБД, LDAP и т.д.)

Роман Дынник

Так, по поводу того, как обстоят дела с mapping’ом на хранимые процедуры
у hibernate. Текущая основная версия это hibernate 2 – хранимые процедуры не поддерживает. Так как эта возможность оказалась очень востребованной пользователями
то в hibernate 3(который сейчас уже на стадии beta-тестирования и доступен для скачивания) уже реализована возможность использовать SP для insert/update/delete – но
не query-support (для load) – hibernate team на этот счет заверяет, что скоро и это будет.

Кроме того, есть примеры реализации собственных Custom Persisters – hibernate позволяет расширить поведение по-умолчанию. Про подобные собственные разработки было слышно еще в 2003 году, когда 3 версии еще не было, так что если интересно можно попытаться связаться с разработчиками через форум на hibernate.org

Кроме того, если SP используются не для insert/update/delete/load, а для реализации других методов объекта – то их использование было возможно всегда через прямое использование jdbc-соединения которое всегда можно получить через session.getConnection(). При этом, так как соединение одно – не возникает никаких проблем с использованием транзакций (без JTA)

В тоже время я для /update/delete/load использую mapping в представления. Что не мешает мне больш у ю часть бизнес логики реализовывать на хранимых процедурах.


Насчет JDO - сейчас на подходе JDO2. В JCP как я понимаю идет война между сторонниками (считай инвесторами) EJB2/3 и сторонниками JDO2. Так что даже не знаю когда стандарт будет принят. Я пока с ним не знаком...

Вышел Hibernate 3

почитать про его возможности можно тут

Очень полезная статья о поддержки хранимых процедур в Hibernate. Интересна главным образом из-за того, что говорит и об отрицательной стороне использования ХП

http://www.hibernate.org/187.html

там есть 16.5. Custom SQL for loading , хотя у меня пока руки не дошли все проверить и выяснить ;)