softwarer
UML -> классы -> структура БД -> работа с классами -> конкретные формы

Выигрывает по сравнению с вариантом

структура БД -> датасет -> форма.



Мне кажется, что во многом это дело вкуса и привычки.
Ко всему в крупных проектах вариант 2 иногда (сам видел) трансформируется в :

UML -> ERD -> структура БД -> датасет -> форма.

Разумеется, когда нужно написать простейшее приложение, то можно просто брать и рисовать структуру БД. Но когда этому предшествует долгий анализ предметной области, а над моделью работает целый коллектив, вариант 1 более эффективен.

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

softwarer
Собственно, на текущий момент у меня есть впечатление, что объекты удобны для сервера приложений - но клиенту удобнее работать с сервером приложений опять-таки через датасеты (или подобные им структуры).


Вот с этим категорически не согласен. Но вероятно впечатления могут сильно зависеть от платформы, на которой идет разработка. С чем работаете вы ?

Я уже несколько начинаю путаться в ваших диаграммах. В одном месте - это последовательность действий при разработке, а в другом - структура приложения ?

Представлю свою точку зрения несколько шире.

1) ORM всегда приводит к замедлению приложения. Очевидно, что прямое обращение к функциям СУБД эффективнее с точки зрения быстродействия.

2) ORM позволяет (и по своей природе подталкивает к этому) рационально разделить приложение на различные функциональные части и работать с каждой из этих частей по отдельности. Например, интерфейсная часть становится более самостоятельной и гибкой. Современные средства разработки все более подводят нас к тому, чтобы мы могли с легкостью подставлять в одно и то же приложение разные "морды" без особого труда. То же самое и с уровнем бизнес-логики. ORM во многом вынуждает выносить логику из хранилища данных и реализовывать ее в приложении в виде отдельного уровня.

3) ORM приводит к изменению процесса разработки. Изменяется порядок отдельных этапов. Это уже хорошо видно из представленных выше диаграмм. Первичными становятся UML-модель и структура классов приложения - структура БД при применении ORM может быть полностью производной от структуры классов приложения и по умолчанию вообще генерируется автоматически. Облегчается документирование в сложных проектах.

4) ORM изменяет логику работы таких механизмов как кэширование и блокировка, переводя ее на уровень отдельных объектов, что может иметь большое значение при разработке приложений определенных классов.

5) Упрощается разработка многозвенных приложений (если в приложении есть четко выраженные различные уровни, то понятнее и проще разделить эти уровни по разным звеньям).

6) Снижаются требования к программистам (нужно просто знать ОО-программирование, знания и опыт использования SQL не обязательны). Как следствие, в сложных проектах снижаются затраты, а небольшие компании получают возможности по созданию и развитию своих продуктов без привлечения дополнительного высококвалифицированного технического персонала.

softwarer
Минус - при операциях на клиенте придется писать код типа DataSet["FieldName"] = Value. В то же время вообще говоря таких операций быть не должно - это делается в объекте, либо по его инициативе (например, инициализация в конструкторе) ...


Конечно, гораздо удобнее обращаться к объектам Object.FieldName = Value без обертки в виде объектов-датасетов и дататаблов. А в случае использования ORM и в конструкторах ничего такого писать не прийдется (в простейшем случае конструкторы вообще можно не писать).

softwarer
2. Передача объекта (через сериализацию или еще как-нибудь) на клиента.


Сразу уточню. Здесь речь идет исключительно о трехзвенке, в которой ORM-инструментарий применяется на уровне сервера приложений. Именно так, в этом случае мы можем передавать (что кстати не обязательно) на клиента объекты. И существующие технологии: WSDL/SOAP/XML-сервисы для .NET и EJB для Java именно под это и заточены. Но я вообще не вижу здесь специфики ORM - ведь DataSet и DataTable тоже объекты и передаются тем же макаром. А в двухзвенке общение с сервером БД идет через SQL-запросы (что с ORM, что без оного).

softwarer
Итого - получается, что основа клиента - это датасетные механизмы, возможно, приспособленные для объектной реальности (например, включающие в себя вызов методов объекта). И я не особо вижу, ради чего городить огород.


Если датасетные механизмы - основа клиента и вы уверены, что это правильно для вашего приложения (переход на классические ОО модели ведет к ухудшению приложения и/или усложняет его разработку), то конечно ORM только навредит, поскольку ориентирован на другие классы клиентов.

softwarer
Проект, опыт которого упоминал - на дельфе, он заканчивается. Вопрос вызван тем, что я обдумываю еще один проект и думаю, использовать ли для него ORM-овскую технологию и, возможно, инструменты. Для него я платформу еще не выбрал - есть аргументы за C#, за дельфу и за джаву.

Для дельфей сейчас активно продвигается ORM-инструментарий Bold. Лично не юзал, но своих адептов эта система уже имеет. Недостатки тоже есть - в основном из-за молодости продукта.

Для .NET уже существует множество решений (Versant Open Access .NET, Hibernate, DeveloperExpress и др.). В целом тоже охарактеризую эти продукты как слишком молодые для того, чтобы с уверенностью говорить о них, как о зарекомендовавших себя в среде разработчиков. Слишком еще молода технология .NET и слишком много в ней неопробованных подводных камней (особенно при построении многозвенных приложений). Тем не менее, знаю что технолдогия активно осваивается и идет немало проектов, в т.ч. и с опорой на ORM-инструменты.

На сегодня именно в мире Java достижения ORM-продуктов наиболее высоки. Обусловлено это как относительной зрелостью платформы Java, так и рядом других факторов, таких например, как явная и строгая объектная ориентированность самого языка программирования Java. Именно в мире Java уже есть устоявшаяся спецификация для обеспечения транспарентной сохраняемости объектов - спецификация JDO. А продукты, реализующие эту спецификацию (по сути ORM-инструменты) обкатаны на множестве проектов. Даже сравнивая известные мне ORM-продукты Versant (Open Access JDO и Open Access .NET), я могу сказать, что VOA JDO ушла по своим возможностям гораздо дальше своей "молодой" родственницы VOA .NET. И реализует огромное число возможностей, ускоряющих и разработку, и повышающих эффективность работы JDO-приложений.

Прежде всего отмечу, что мои 6 пунктов вовсе не обязательно являются плюсами (и вы это вроде бы заметили). Все зависит от конкретики вашей задачи.

>Меня больше интересует тот факт, что взаимодействие объектов с интерфейсом хорошо описывается именно dataset-ориентированными механизмами, и собственно не имеет разумной альтернативы. Соответственно, приспособить эти механизмы под работу с объектами представляется мне единственным решением. Ну и помним, что dataset-ы реализуют набор типичных операций, которые понадобятся и для других случаев - сортировку и прочее.

Вот тут вы поднимаете основное отличие объектного подхода. Взаимодействие объектов с интерфейсом совсем не обязательно оптимально при ориентации на dataset-конструкции. Если пользователь в основном работает с таблицами, а не с формами для редактирования объектов (элементов таблиц), а поиск нужных данных осуществляет через сортировку и визуальный перебор записей, то объектный подход здесь не катит. При ОО-программировании нужно уходить от работы пользователя с таблицами. Преимущественно должны использоваться специализированные формы для редактирования конкретных объектов, а поиск должен базироваться в первую очередь на разнообразных методах навигации (по деревьям и другим видам графов, по связям между объектами). Т.е. меняется сама идеология построения интерфейсов и это первое, что вы заметите, когда перейдете на Java - там даже нет много из того, к чему привыкли разработчики Delphi или Access - и некоторая "ломка" поначалу многих напрягает.

Почитайте это .

Важно понять то, что же вы все-таки имеете ввиду говоря о двухзвенке и трехзвенке. Если у вас нет уровня бизнес-логики, то как можно говорить о том реализован ли он на клиенте или на сервере? Если же у вас на сервере абстрактный уровень бизнес-логики реализован с помощью хранимых процедур и триггеров, то следует понять одну простую вещь - если абстрактный уровень бизнес-логики в приложении имеется (его можно явно выделить в архитектуре приложения), то это как минимум трехзвенная архитектура.

Хранимые процедуры и триггеры реализованы внутри СУБД только лишь по причине удобства развертывания и это в некотором смысле ограничение (мы не можем, например, заставить систему отрабатывать триггеры на отдельном сервере). Пожертвовав этим удобством до некоторой степени (усложнив развертывание), вы можете разместить на этом же сервере свое приложение, которое будет отрабатывать всю бизнес-логику и отвечать за передачу данных, например через Web-сервисы, вашему (полу)тонкому клиенту (во всех случаях мы вправе говорить о клиент/серверной архитектуре системы). Т.е. если сам уровень бизнес-логики есть, то его размещение - вопрос отдельный. Но именно наличие этого уровня (как бы он ни был реализован) позволяет отнести приложение к трехзвенному.

Именно в такой трактовке трехзвенности я совершенно согласен с funikovyuri - средства ORM зря привязывают к вопросу о том, где должна происходить обработка данных или бизнес-логика приложения. Средства ORM тоже можно разместить как на стороне клиента (толстый клиент), так и на стороне сервера ((полу)толстый клиент).

Что же касается различий между "суррогатами-обертками" (ака DataTable и DataSet) и "настоящими объектами", то советую просто сравнить способы доступа к связанным объектам. Т.е. как в обоих случаях мы можем, к примеру, получить список неких сущностей, связаных с исходным объектом каким-нибудь отношением. Разумеется, вы увидите, что в истинных объектах существует возможность НАВИГАЦИИ, тогда как для суррогатов ничего такого нет.

vadiminfo
Ограничения целостности, которые нельзя выразить декларативно в РСУБД в разных источниках назваются по разному: корпаративные ограничения целостности, ограничения общего вида, бизнес ограничения.
...
Если это реализовать в приложении, а не хранить в виде триггера вместе с данными, то будет зависимость данных от приложения (без этого приложения этого правила нет, и целостность данных зависит от этого приложения).
...
Целостность данных - одна из трех составных частей модели данных. ... зачем нужны ограничения целостности в модели данных. Ну, можно предположить, что ограничения целостности это свойства, которые должны быть либо истинными, либо ложными для каждого возможного состояния данных. Т.е. они обеспечивают логические правила, которым отвечают данные в БД в любом состоянии. Их вводят как для повышения семантичности модели данных так и расширения возможностей поддержки целостности данных. Разве мы в этом не заинтересованы? Т.е. польза от них есть? Но необходимы ли они? В РМД скорее всего да. Без них модель менее адекватно отображает предметную область (ПО). А цель моделирования максимально адекватно отобразить ПО.
Про ООМД, что-то читал, что там с ними сложности, но точно не помню.


Ну сложности совершенно очевидны. И они проистекают из того, что в ООБД могут храниться объекты любых классов (типов). Строгая типизация, характерная для РСУБД позволяет системе свободно обращаться с данными, поскольку операции над этими данными уже определены и сама СУБД их знает и умеет исполнять. Т.е. когда нам нужно ограничить, например, максимальное значение, то мы можем спокойно вписать ограничение вида «не больше». Но как сравнивать объекты, операция сравнения которых не определена или переопределена в классах-потомках? И даже если сам код этой операции хранится вместе с описанием соответствующего класса, то всегда ли эффективно выполнять этот код «внутри» СУБД? Пока что на эти вопросы нет однозначного ответа. Versant проповедует подход, позволяющий отдать решение этой проблемы на откуп разработчику. GemStone хранит и исполняет методы средствами сервера БД, т.е. все вопросы должны решаться внутри СУБД.

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

Рассмотрим примеры

Выше mir привел пример с необходимостью использования триггера для обеспечения целостности данных при наличии неких аггрегатов (типа суммы). Кажется, что в данном примере наличие триггера действительно ТРЕБУЕТСЯ для обеспечения целостности данных. Но давайте разберемся в этом детальнее. Рассмотрим две крайних ситуации.

1) Предположим у нас есть таблица с полями v1, v2, v3, vAgr. В такой ситуации я безо всякого тригера наложу ограничения, которые запретят запись в поле суммы vAgr любых значений, не равных сумме полей данных (v1, v2, v3), а в поля данных - любых значений кроме тех, которые не противоречат существующему значению суммы. В результате целостность данных будет обеспечена, но приложение просто должно будет вычислять сумму самостоятельно и изменять соответствующее поле в рамках одной транзакции с изменениями полей данных.
2) Предположим теперь, что vAgr должно содержать наибольший общий делитель значений v1, v2, v3 или наименьший по модулю корень кубического уравнения, коэффициенты которого определяются значениями v1, v2, v3 или т.п.

Что же оказывается? В первом случае для обеспечения целостности нам триггер в принципе не обязателен, а во втором – реализовать все необходимые вычисления даже в рамках триггера проблематично, да и не факт, что это будет разумно с точки зрения распределения вычислительной нагрузки между серверами и клиентами.

Вопросы, вопросы, вопросы...

Где же та граница, за которой мы можем говорить, что вот «это» относится к целостности данных и должно отрабатываться внутри СУБД (с помощью триггеров, ХП или как-то еще), а вот «то» уже нет и имеет право быть перенесенным в приложение? По какому критерию мы относим одни правила к модели предметной области, а другие готовы признать функцией приложения?

По логике некоторых постов в этой ветке мы должны реализовать в виде хранимых процедур все. Причем реализовывать бизнес-логику в виде хранимых процедур даже правильнее, чем как-то иначе! Почему так? Что, кроме соображений быстродействия и удобства развертывания за этим стоит? Целостность данных? Но бизнес-правила могут измениться и тогда в процессе переписывания и доработки хранимых процедур целостность данных окажется под угрозой. А если обработка бизнес-правил вынесена на сервер приложений, то беспокойства по крайней мере за судьбу уже накопленных данных быть не должно. Читая посты некоторых товарищей вобще приходишь к выводу, что выделять отдельный уровень бизнес-логики в приложениях нет необходимости – за все в ответе СУБД?

Проблема распределения вычислительной нагрузки

Зачем же я задаю столько вопросов и не даю на них четких ответов? Мне кажется, что нет никаких четких критериев, по которым мы можем относить одни ограничения и правила к компетенции СУБД, а другие – к компетенции приложения. На практике все определяется задачами разделения вычислительной нагрузки и удобством разработчика. Т.е. когда разработчик хочет снять нагрузку с сервера БД, он включает вычисления и проверки в приложение, а когда ему хочется облегчить управление проектами, где множество разных приложений пишется для работы с одной базой, а нагрузка на сервер разрешена большая, он реализует многие обработки в виде хранимых процедур и триггеров. Очевидно, что в идеале мы должны иметь возможность гибко выбирать то звено приложения, на котором мы хотим исполнить наш код (проверка бизнес-правила, реакция на событие и т.п.). Т.е. вот захотели, чтобы эта процедура выполнялась на сервере приложений – поставили птичку и забыли. А эта на сервере БД – пожалуйста. На клиенте – нет проблем. В таком контексте хранимые процедуры на SQL становятся скорее тормозом, ограничивающим гибкоть приложений. Ведь не зря сейчас пошла волна встраивания в СУБД поддержки платформонезависимых языков (Java, да и .NET), выполнение кода которых можно легко перемещать между различными серверами/клиентами.

Выводы

Какой вывод я бы хотел сделать из всего сказанного? Вероятно очень важно хранить вместе с данными (или где-то рядом) формальные описания правил обеспечения целостности этих данных. Но вот вопрос о том, в каком звене информационной системы (клиент/сервер приложений/сервер БД/ ... ) эти правила следует отрабатывать не столь однозначен.

Сегодня исходные тексты (или байт/IL-коды) процедур/методов, написанных на Java или языках платформы .NET в принципе можно хранить в БД. Это поддерживает Oracle (ХП на Java), Юкон (.NET), Versant Developer Suite (Java) да и любая СУБД (по большому счету нет проблем хранить исходники в БД). Но возможность переноса нагрузки пока только в незначительной мере реализуется системами с полноценными серверами приложений. Это так хотя бы потому, что реализуя всю бизнес-логику и правила обеспечения целостности в рамках сервера приложений мы можем решать, ставить ли нам сервер приложений на тот же компьютер, где у нас стоит сервер БД или на отдельный. Если же вся бизнес-логика реализована в виде ХП внутри одной БД и лежит вместе с данными, то современные РСУБД не дают нам никакого выбора – отработка этих ХП будет происходить на том же сервере.

На мой взгляд вполне можно смотреть на связку «СУБД+сервер приложений» как на единое хранилище данных и методов и именно эту пару рассматривать, как систему, обеспечивющую непротиворечивость и целостность данных, а также как на собственно реализацию модели предметной области. И все равно это будет только некоторым приближением, поскольку и приложение тоже не является только витриной к хранящимся данным и некоторые элементы бизнес-логики иногда логичнее реализовывать именно в рамках пользовательских приложений (какие именно – решает разработчик в свете реальных требований в конкретных ситуациях).

vadiminfo
Про Дейта. Он безапеляционно отверг сам SQL как "искажение" реляционной модели, а вместо него вместе с Дарвеном предолжил язык D (1992). Насчет триггеров ничего не ясно из моих источников, ... А почему Вы упомянули Дейта? Ведь даже Кодд - отец РМД, но он выпустил Джина. Включились значительные интеллектальные ресурсы. Их не сбросишь со счетов. Разве та теория множеств Кантора, которую он сам создавал не называется сегодня "наивной". Хотя безусловно он отец теории множеств вообще и гений гениев. Но тысячи спецов, среди которых были и выдающиеся
не зря ведь работали. Были созданы новые разделы в математике. Она вообще приняла другой вид...


Согласен.
Я тут на досуге немного поисследовал – за что же Дейт критиковал ООСУБД в ряде своих статей. Забавный перечень:

1. Совместное использование данных приложениями
2. Физическая независимость данных
3. Непредвиденные запросы
4. Представления и логическая независимость данных
5. Независимые от приложений декларативные ограничения целостности
6. Владение данными и гибкий механизм безопасности
7. Управление многопользовательским доступом
8. Каталог общего назначения
9. Независимое от приложения проектирование базы данных

Создается впечатление, что разработчики ООСУБД последние 10 лет работали строго в направлении, указанном Дейтом, и старательно исправляли все названные недочеты. Сегодня практически по всем пунктам в ООСУБД есть соответствующая функциональность и только некоторые вызывают вопросы, причем вопросы эти носят скорее концептуальный, чем технический характер.

Офф-топ. Пардон.
Не туда послал сообщение. Впрочем - возможно вам тоже будет любопытно.