Объектно-компонентная платформа создания приложений БД

[Dimka]

Появилась новая статья на тему subj. Хотелось бы знать, автор эту тему будет развивать как-нибудь дальше или нет?

Дело в том, что эта тема меня сейчас очень занимает, однако описанный подход (который я благополучно использую в своей работе) уже начинает неудовлетворять. Дело в том, что предложенное решение хоть и применяется Microsoft, однако не совсем отделяет данные базы от объектов предметной области. Для более гибкой архитектуры приложений, моделирующих бизнес-процессы, хочется ввести ещё один слой (уровень) объектов между описанными в статье (скажем так, объектами данных) и интерфейсом пользователя. Уровень бизнес-логики. На нём все ADO .NET объекты уже не должны быть видны. В то же время интерфейс строился бы на базе объектов бизнес-логики, а не использовал бы DataSource. Описанный в статье подход удобен для небольших проектов, но для более крупных, нуждающихся в постоянном сопровождении, тянуть за собой таблицы при каждом изменении очень утомительно.

Пока яснее сказать не могу - могу лишь на примере показать (если это кого-нибудь заинтересует). Интересует вышеописанное развитие данной темы. Ещё более ценными были бы статьи, основанные на практическом опыте реализации и успешного применения.

[автор темы]

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

вы писали:
"Дело в том, что предложенное решение хоть и применяется Microsoft, однако не совсем отделяет данные базы от объектов предметной области. Для более гибкой архитектуры приложений, моделирующих бизнес-процессы, хочется ввести ещё один слой (уровень) объектов между описанными в статье (скажем так, объектами данных) и интерфейсом пользователя. Уровень бизнес-логики."

я комментирую:
То что я описывал встатье, по моему и есть то, что вы хотите, отделение прикладной области от БД. Те классы что описывались, они знают о БД (а как же иначе это же платформа!?), но тому коду что будет использовать данную платформу уже необязательно знать что-то структуре БД и т.п.
И это все реализуется метаданными, которые, используются для работы классов, визуальных компонентов, форм и т.п., входящих в платформу.

Таким образом и получается, что прикладная область отделена от самой БД, слоем, этой самой платформой о которой я писал.

вы писали:
"В то же время интерфейс строился бы на базе объектов бизнес-логики, а не использовал бы DataSource."
А, GUI в предлагаемом решении и строится на базе объектов бизнес-логики, которые поддерживают соответствующий interface.

вы писали:
"Описанный в статье подход удобен для небольших проектов, но для более крупных, нуждающихся в постоянном сопровождении, тянуть за собой таблицы при каждом изменении очень утомительно."
я комментирую:
вы имеете таблицы метаданных?

Насчет примера, я бы с удовольствием посмотрел на него a_lexandr@mail.ru в своем почтовом ящике, ну или здесь, в форуме.

[Dimka]

понятно, что непонятно

перечитаю ещё раз...

да, метаданные мы используем, может немного в ином виде, в есть таблица таблиц, таблица связей таблиц, таблица прав

и опять не понял... как идёт работа с атрибутами класса? как синхронизируются атрибуты объекта и поля записи? Если объект работает с полями записи напрямую - это не то, что хотелось бы.

далее, важно не увлекаться трафиком между SQL Server и приложением. Т.е. по возможности выборку и элементарные преобразования вести на стороне СУБД в рамках одного большого запроса, а не на клиенте - на клиенте в нашем случае недопустимо тормозит, кушает много памяти и демонстрирует всяческую неэффективность. Т.е. в ходе запроса мы получаем DataSet, на таблицах которого уже создаются объекты.

правильно ли я понимаю, что объект - это некое окно в набор данных? Т.е. через объект работа идёт с 1 записью, но объект можно перемещать по записям коллекции (как стекло в логарифмической линейке или как машина Тьюринга на ленте памяти )?

[автор темы]

На самом деле, многие не понимают , что там написано, наверное, потому, что я переборщил с краткостью. Именно поэтому, и не только, собираюсь дописать, или переписать, сделать статью более полной и т.п., возможно даже с примерами из реальной жизни.

А, Вам могу только посоветовать перечитать повнимательнее весь раздел "Метаданные", то есть обратить внимание на содержимое таблиц и на код, что был приведен.

и опять не понял... как идёт работа с атрибутами класса? как синхронизируются атрибуты объекта и поля записи? Если объект работает с полями записи напрямую - это не то, что хотелось бы.

Не очень понял, что вы имели ввиду, но, на всякий случай скажу, что класс не сериализуется в БД.

правильно ли я понимаю, что объект - это некое окно в набор данных? Т.е. через объект работа идёт с 1 записью, но объект можно перемещать по записям коллекции (как стекло в логарифмической линейке или как машина Тьюринга на ленте памяти  )?

нет, не правильно.
Объект, конечно можно назвать окном в БД, но работает он со всей сущностью целиком, как например, оператор select, впрочем и в select можно ставить условие и он выберет 1 строку! ))

[Alf]

На самом деле, многие не понимают , что там написано...

Увы, сам я тоже вхожу в число этих многих.
Посему вопрос к читателям: кто из семи десятков прочитавших статью может, положа руку на сердце, сказать, что он понял все из написанного? Было бы любопытно.

[x77]

Alf, да всё, в общем-то, понятно. но у меня класс, работающий непосредственно с базой, вынесен отдельно. его задача блюсти коннект аки честь смолоду, по мере надобности стартовать и откатывать транзакции на конкретные действия. классы - "сущности" наследуются уже от него, и о базе, в общем-то, имеют довольно смутное понятие, здесь уже и начинается бизнес логика. причём класс пользователей, например, может включать в себя класс, отвечающий за их права в системе, т.е. они могут быть вложенными. а уже в коде основной проги мне вообще пофигу все на свете базы, я просто работаю с классом как с обычным объектом, редактирую, настраиваю для просмотра и т.д., как это будет отрабатываться на уровне базы - это проблемы как раз вот этой "платформы", о которой идёт в речь в статье.

может быть, я неправильно всё понял, ну тогда автор поправит

[Alf]

x77, значит, все-таки проблемы именно со мной, поскольку я не понял целый ряд моментов:

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

2. Зачем сущности знать собственную строку соединения со своей БД. Вроде бы как цель данной статьи - абстрагироваться от базы, перейдя к объектам (впрочем, относительно цели см. ниже). И тут же вылезает самый что ни на есть низкоуровневый атрибут, да еще и видимый публично. Ладно бы еще объект типа Connection, при объектном подходе он был бы уместнее...

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

4. Для каждой операции с сущностью (например, для редактирования) явно создается соединение, а по окончании - разрывается. Это все может пройти, если операций относительно мало. В случае достаточно протяженной сети с ощутимыми задержками создание соединения может повлечь существенные накладные расходы, особенно сервер баз данных нагружен. У меня, например, с некоторыми серверами соединение открывается до нескольких секунд. Страшно подумать, если понадобится добавить несколько тысяч записей.

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

[AlexandrV]

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

Для расширения функционала базового класса, можно:
- создать класс, наследник CDBEntity;
- или класс реализующий интерфейс IDBEntity.

Пожалуй это все, что так длинно описывается в самой статье. А самое интересное, что должно быть прописано в таблицах метаданных, для работы класса CDEntity?! 8) ))

[Alf]

Alf, да всё, в общем-то, понятно.
<skipped>
может быть, я неправильно всё понял, ну тогда автор поправит

То есть все понятно, что ничего не понятно? Тогда я не одинок в этом.  

[x77]

Alf,

1. а что ты называешь сущностью? понятие сущности, данное в статье отличается от сущности в традиционной ER-модели. сущностью может быть, в конечном счёте, цех. который будет включать в себя такие сущности, как сотрудники, товары, счета и пр. и отчёт, насколько я понимаю, ты можешь формировать на любом уровне.

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

3. в том-то и дело, что права, как правило, назначаются не на уровне субд, а на уровне бизнес-логики. мне надо управлять правами юзеров не на чтение/запись таблиц (что, конечно, надёжнее), а на получение события от контроллера, например, или на право доступа к отчётным данным, формируемым достаточно сложной выборкой и не только из таблиц. и здесь неминуемо придётся разрабатывать свою систему прав, по возможности увязывая её с правами на уровне субд. но это не всегда удаётся и всегда приносит доп. геморрой.

4. в принципе, напрямую зависит от п.2., уже всё сказал.

[AlexandrV]

Alf,
1. все отчеты должны быть "привязаны" к каким-то сущностям, например, отчет по выполненным заказам, может быть привязан к сущности "заказ", но в нем могут использоваться и другие сущности: "компания", "склад", и т.п.
самое главное это сформировать набор данных (который формируется соответствующей командой sql), а как его вызвать для формирования, и, прописано в метаданных.

2. Вообще у меня есть перегруженный конструктор, в который вместо строки соединения передается объект SqlConnetcion, что сразу снимает вопрос номер 4 вашего комментария.

3. проверка делается для того, что бы пользователь, случайно, не удалил, не увидел, не отредактировал то, что ему собственно говоря и не нужно удалять, видеть, редатировать из пользовательского интерфейса, то есть для одного пользователя будет видна кнопочка удалить, для другого нет.

[Alf]

Alf,
2. Вообще у меня есть перегруженный конструктор, в который вместо строки соединения передается объект SqlConnetcion, что сразу снимает вопрос номер 4 вашего комментария.

Не уловил связи между этими двумя, в общем, разными вопросами.

Во-первых, в определении интерфейса

Код:

public interface IDBEntity
|
string EntityName
| get; "
string ConnectionString
| get; "

строка соединения присутствует безотносительно к тому, каким конструктором создавалась сущность. Так что без изменения интерфейса никуда эта строка не денется.

Во-вторых, наличие/отсутствие открытого доступа сущности к низкоуровневым данным, относящимся к соединению, никоим образом не диктует нам стратегию использования самого соединения, держать ли его открытым весь сеанс или открывать на каждую транзакцию.
Кстати, весьма здраво этот вопрос решен в ADO.NET, вполне можно было бы заимствовать их решение.

[AlexandrV]

Alf, В статье, я использовал, немного упрощенный вариант описания платформы для доступности понимания принципа лежащего в предложенном подходе. А уж как вы его будете реализовывать, если конечно будете, ваше дело.
И, именно поэтому, в интерфейса описана строка соединения, а не, класс SqlConnection, который впрочем, действительно, не обязательно должен быть public (лучше конечно protected).

Имелось ввиду, что если передаваемый экземпляр класса SqlConnection был открыт ранее, то в методах класса CDBEntity, им можно будет пользоваться для доступа к БД, не открывая, и не тратя при этом время на коннект.

[Dimka]

попытаюсь описать, как я себе представляю объектный подход в БД.
1. Есть 2 разные вещи: хранилище и модель предметной области. Хранилище отражает модель в той части, в какой это требуется самой модели.
2. Модель предметной области представляет собой взаимодействующие объекты классов. Взаимодействия образуют поведение системы.  Взаимодействия осуществляются "посылкой сообщений" или вызовом методов, проще говоря. Эта часть, надеюсь, всем понятна.
3. Требуется хранить часть информации (часть значений атрибутов объектов) в хранилище для того, чтобы не держать приложение в runtime постоянно. Т.е. задача хранилища хранить состояние системы длительное время (в том числе вне runtime).
4. Задача: создать механизм сохранения/восстановления состояний объектов системы, причём этот механизм должен быть отделён содержимого методов объектов системы (т.е. чтобы методы не выполняли множество дополнительных операций синхронизации данных, к логике этих методов не относящиеся).

Короче говоря, если попадается мне код на сопровождение, где описан какой-либо бизнес-процесс, то вместо того, чтобы видеть внятный на 1 экран алгоритм работы процесса, я вижу сотни строк кода, где в поля DataRow записываются данные, или foreach() циклы, где эти данные извлекаются. И в недрах этого всего реализована собственно бизнес-логика. И избавиться от этого кошмара при существующей архитектуре невозможно, потому что данные хранятся в DataRow, DataTable, и механизмы логики используют их для своей работы. Причём эти же DataTable используются в качестве DataSource для элементов управления пользовательского интерфейса. В результате, вместо 5-минутной работы изменения бизнес-процесса согласно новым пожеланиям заказчика я трачу часы, чтобы понять, какие данные из каких таблиц извлекаются, куда записываются.

Как в MFC реализован механизм DDE между объектами и элементами управления - примерно то же хочется создать на границе БД - Объекты предметной области. Дополнительные 5% кода в файле, не относящиеся к делу, стерпеть можно, но когда их 50% - это, имхо, недопустимо.

[Alf]

AlexandrV, похоже, источник всех недоразумений кроется в том, что статья задумывалась как концептуальная, а получилась как описание некоей реализации, причем скудно документированной, и читатель вынужден по фрагментам кода сам улавливать основные идеи, которые явно в статье не выражены. Так сказать, своеобразный reverse engineering статьи...

Думаю, статья была бы гораздо доходчивее, если бы у читателя была возможность сначала ознакомиться с основными идеями, без деталей реализации, в рафинированном виде. Например, диаграмма классов UML куда нагляднее и информативнее, да и к языку практически не привязана.

И число глупых вопросов сразу же уменьшилось бы, разговор пошел бы по существу.

[AlexandrV]

Alf, Я, согласен, дело еще и в том, что это моя первая статья, и, она действительно получилось несколько скомканной и т.п., но в ближайшее время, я, исправлю это недоразумение, то есть расширю, углублю & etc.

dimka, Собственно говоря, примерно так оно и будет, если конечно вам на сопровождение не попадется сама платформа.

[Alf]

AlexandrV, лиха беда начало. Вполне может роскошный цикл статей получиться, если все в порядок привести.

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

Лучше начать с постановки задачи: зачем вообще нужно тащить объектный подход в разработку приложений БД, что мы выиграем, если спрячем поглубже технические детали взаимодействия объекта, моделирующего некоторую сущность, с хранилищем данных, и т.д.

Потом самое время для объектной модели, которая отражает абстракцию сущности в данной системе. Лучше не прятать суть за описаниями интерфейсов на конкретном языке программирования, а сначала показать наглядно в виде диаграмм UML.

Ну а потом уже, конечно, придет черед показать детали, желательно с примерами.

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

Если нужны услуги рецензента, могу попробовать помочь.

[AlexandrV]

Alf, Спасибо, возможно, что так и будет!:))