Я пишу типичную программу для работы с БД MS SQL Server. Соответственно есть GUI и DAL(Data Access Layer).

В книгах и журнальных статьях по программированию и архитектуре ПО много пишут о необходимости ввода в архитектуру программы уровня модели (Model Layer — ML).

Имеет ли смысл мне вводить такой уровень? В моём случае получается, что объекты модели повторяют (может не совсем "дословно") схему БД. Или я не правильно проектирую ML?

Здравствуйте, <Аноним>, Вы писали:

А>В книгах и журнальных статьях по программированию и архитектуре ПО много пишут о необходимости ввода в архитектуру программы уровня модели (Model Layer — ML).
Быть может подразумевается Business Logic Layer (BLL) или шаблон проектирования Model-View-Controller (MVC) / Model-View-Presenter (MVP)?

А>Имеет ли смысл мне вводить такой уровень? В моём случае получается, что объекты модели повторяют (может не совсем "дословно") схему БД. Или я не правильно проектирую ML?
Это нормально: БД хранит данные, а приложение с BLL позволяет производить обработку данных в памяти, то есть без обращения к БД при каждом чихе (а именно так у вас и происходит в приложении только с двумя слоями: DAL и PL). При этом, разумеется, можно сказать, что BLL повторяет структуру БД на объектах. В принципе, здесь уже это обсуждалось: Re: Вопрос начинающего

Автор: rsn81
Дата: 13.06.07

Здравствуйте, rsn81, Вы писали:

R>Быть может подразумевается Business Logic Layer (BLL) или шаблон проектирования Model-View-Controller (MVC) / Model-View-Presenter (MVP)?
Совсем не обязательно модель совмещена с BL, не смотря на заявления Фаулера. Совсем не обязательно она является частью MVC. Во всех моих последних проектах модель — сквозной слой, сильно завязаный на БД. Есть у меня тут одно Legacy где модель у каждого слоя (DAL, HB, Web Service) своя. Меня такой дизайн сильно напрягает.

Здравствуйте, Аноним, Вы писали:

А>Я пишу типичную программу для работы с БД MS SQL Server. Соответственно есть GUI и DAL(Data Access Layer).
А>В книгах и журнальных статьях по программированию и архитектуре ПО много пишут о необходимости ввода в архитектуру программы уровня модели (Model Layer — ML).
А>Имеет ли смысл мне вводить такой уровень? В моём случае получается, что объекты модели повторяют (может не совсем "дословно") схему БД. Или я не правильно проектирую ML?

В большинстве случаев такой слой очень нужен. И да он тесно зачастую связан с моделью базы. По причине такой связи и создаются различные ORM. У этого слоя большой "запас" для повторного использования во всех слоях системы.
Хотя бывает что такой слой и ни всегда нужен. Например, когда слою бизнес логики все равно с какими табличными данными работать. Хотя модель в таких системах присутствует, но она завязана не на саму базу а на её мета данные, то есть вся модель выглядит как Таблица, Строка, Колонка, Ячейка и пр.

Здравствуйте, Blazkowicz, Вы писали:

B>Совсем не обязательно модель совмещена с BL, не смотря на заявления Фаулера. Совсем не обязательно она является частью MVC. Во всех моих последних проектах модель — сквозной слой, сильно завязаный на БД. Есть у меня тут одно Legacy где модель у каждого слоя (DAL, HB, Web Service) своя. Меня такой дизайн сильно напрягает.
Так это, разве баба Яга против?
Во всех последних работах BLL-объекты насквозь прошивают приложение:

1. DAL: обобщенный DAO-объект загружает/сохраняет данные BLL-объекта из/в соответствующего хранилища: БД, файловая система, Интернет-ресурс, память и etc.
   
2. PL: BLL-объект встраивается с помощью обобщенного медиатора в MVP (Model-объект; суть описывал в своей статье про MVC).

При этом достаточно вкусным оказалось встраивание контрактов в BLL-объект (это я про обсасываемую с недавних пор в разделе Java библиотеку OVal): с одной стороны, безопасность прошивания DAL (не взирая на то, поддерживает или нет конкретная БД ссылочную целостность и всевозможные пред- и постпроверки, на линию соединения с БД просто не могут попасть некорректные данные, так как они не могут появиться даже в памяти приложения), а с другой стороны, минимизация работы по интерфейсу пользователем, который не допускает ввод некорректных данных в графические формы — таким образом прошивание BLL-объекта всего приложения насквозь дает дополнительные бонусы.
Меня такой дизайн пока на сильный рефакторинг не напрягал.

Здравствуйте, Blazkowicz, Вы писали:

B>В большинстве случаев такой слой очень нужен. И да он тесно зачастую связан с моделью базы. По причине такой связи и создаются различные ORM. У этого слоя большой "запас" для повторного использования во всех слоях системы.

Единственное предназначение ML — создание "запаса"? Нет? А какое? Какая часть логики может\должна быть в ней? Исключает ли она обращения к DAL отовсюду, кроме как "из себя"?

Здравствуйте, _FRED_, Вы писали:

_FR>Единственное предназначение ML — создание "запаса"? Нет? А какое?
создание "языка" взаимодействия слоёв..

_FR>Какая часть логики может\должна быть в ней?
если будет валидация т.е проверка выполнения контрактов, то будет хорошо (пост rsn81 объясняет почему).
Другой тип логики — поведение, пока не понятно будет в ней или нет, видимо решается по дополнительным критериям...
может еще какой тип логики пропустил?..

_FR>Исключает ли она обращения к DAL отовсюду, кроме как "из себя"?
как я думаю, к DAL надо обращаться из Application Layer, этакого слоя-клея,. чтобы не засорять модель, и PL сюда не мешать — только логика, и ни_каких технических подробностей.

сам обо всём этом точно не знаю, пишу сложившееся представление оптимального решения, поправьте если я не прав

Здравствуйте, <Аноним>, Вы писали:

А>Имеет ли смысл мне вводить такой уровень? В моём случае получается, что объекты модели повторяют (может не совсем "дословно") схему БД. Или я не правильно проектирую ML?

Этот слой имеет смысл вводить, если предполагается использование модулей расширения. В этом случае такой слой изолирует эти самые расширения от специфики DAL, навроде разметки для ORM, вычисляемызх полей, кеширования etc. Еще такой слой можно использовать при формировании контрактов для удаленного доступа, но далеко не всегда конкретный OORPC позволяет делать сериализацию по формальным контрактам.

Если я буду использовать DAL и BLL (Business Logic Layer), например BLT (http://www.bltoolkit.net). То смогу ли я связывать графические компоненты с данными по средством BindingSource? И как определять изменённые записи и производить обновление БД, это я как понимаю делает DataSet, DataTable (в смысле определения изменений данных), а раз их не использовать то как, всё в ручную что ли?

Здравствуйте, kejroot, Вы писали:

_FR>>Единственное предназначение ML — создание "запаса"? Нет? А какое?
K>создание "языка" взаимодействия слоёв..
Очень метко подмечено. Можно его назвать и "инфраструктурой". Это модель для наилучшего представления данных, оптимального для отображения "реальных" сущностей на код и отображения бизнес правил на логику.
"реальных" в кавычках, потому что сущности модели не всегда имееют конкретное отображения на термины предметной области. Часто сущность модели может быть и специфичной именно для конкретного проекта и совершнно абстрагированой от жизни.

_FR>>Какая часть логики может\должна быть в ней?
K>если будет валидация т.е проверка выполнения контрактов, то будет хорошо (пост rsn81 объясняет почему).
K>Другой тип логики — поведение, пока не понятно будет в ней или нет, видимо решается по дополнительным критериям...
K>может еще какой тип логики пропустил?..
Лично у меня критерий один. Если логика ограничивается самой моделью и слоем бизнес логики, то её можно поместить в модель. Все остальные интеграционные моменты работы с представлением, доступом к БД, вызовом различных публичных интерфейсов описаны в слое бизнес логики. Потому как модель — код, зачастую, сквозной, и тащить за собой другие интеграционные "сопли" сквозь весь проект через него не хорошо.

_FR>>Исключает ли она обращения к DAL отовсюду, кроме как "из себя"?
K>как я думаю, к DAL надо обращаться из Application Layer, этакого слоя-клея,. чтобы не засорять модель, и PL сюда не мешать — только логика, и ни_каких технических подробностей.
Да, как я и попытался описать выше. Если операции ограничиваються моделью, то можно логику в нее и поместить.

Кстати Марти Фаулер с таким подходом категарически не согласен:
http://martinfowler.com/bliki/AnemicDomainModel.html
(Эта статья здесь уже неоднократно обсуждалась)

Здравствуйте, Аноним, Вы писали:

А>Если я буду использовать DAL и BLL (Business Logic Layer), например BLT (http://www.bltoolkit.net). То смогу ли я связывать графические компоненты с данными по средством BindingSource? И как определять изменённые записи и производить обновление БД, это я как понимаю делает DataSet, DataTable (в смысле определения изменений данных), а раз их не использовать то как, всё в ручную что ли?

Обьновление в СУБД производится посредствои операции
unitOfWorkObjectAsInFowler.Save(someBusinessObject).

Задача определения была ли запись изменена ложится на используемый ORM и совершенно не колебёт разработчика никаким боком. Вопрос как маппер определяет слудет ли апдейтить запись или ничего не поменялось зависит от маппера. Кстати по теме — мож кто в курсах как это делает ( и делает ли вообще ) NHibernate?

Здравствуйте, Aviator, Вы писали:

A>Обьновление в СУБД производится посредствои операции
A> unitOfWorkObjectAsInFowler.Save(someBusinessObject).

Всё таки я не понял как сохранять в БД?

Пример на сайте http://www.bltoolkit.net/Doc/DataAccess/Insert.htm показывает как в ручную вызывать хранимую процедуру.

Например для SqlDataAdapter я создаю команду для вставки и вызываю da.Update(table). А для BLT как делать.
Может кто-нибудь подскажет пример. На сайте http://www.bltoolkit.net нет нормальной документации использования BLT от начало и до конца (привязка к DataGridView).

Здравствуйте, Аноним, Вы писали:

А>Например для SqlDataAdapter я создаю команду для вставки и вызываю da.Update(table). А для BLT как делать.
А>Может кто-нибудь подскажет пример. На сайте http://www.bltoolkit.net нет нормальной документации использования BLT от начало и до конца (привязка к DataGridView).

А для NHibernate есть документация здесь .

Здравствуйте, <Аноним>, Вы писали:

А>Например для SqlDataAdapter я создаю команду для вставки и вызываю da.Update(table). А для BLT как делать.
А>Может кто-нибудь подскажет пример. На сайте http://www.bltoolkit.net нет нормальной документации использования BLT от начало и до конца (привязка к DataGridView).

Ты ходи сюда Business Logic Toolkit

Здравствуйте, <Аноним>, Вы писали:

А>Может кто-нибудь подскажет пример. На сайте http://www.bltoolkit.net нет нормальной документации использования BLT от начало и до конца (привязка к DataGridView).

В dev версии проекта есть два примера: один для WinForms, второй переделанный PetShop.

Здравствуйте, Aviator, Вы писали:

A>Кстати по теме — мож кто в курсах как это делает ( и делает ли вообще ) NHibernate?

It depends. Если с объектом работают в пределах одной сесси (ISession), то обновляться могут как все поля, так и только измененные -- это контролируется в маппингах (dynamic-update в class). Если же объект прицепили к новой сессии (например, прочитали из БД, передали на клиента, а он вернул измененную копию и ее надо записать), то обновляться будут все поля, поскольку никакой служебной информации об измененных свойствах у NHibernate, очевидно, нет.

Ну и кое-какие тонкости есть.

Здравствуйте, Blazkowicz, Вы писали:

B>... Если логика ограничивается самой моделью и слоем бизнес логики, то её можно поместить в модель. Все остальные интеграционные моменты работы с представлением, доступом к БД, вызовом различных публичных интерфейсов описаны в слое бизнес логики.
B>Кстати Марти Фаулер с таким подходом категарически не согласен:
B>http://martinfowler.com/bliki/AnemicDomainModel.html

а по-моему он согласен (не согласен он выделять "domain logic" в сервисы), это тот же подход: Ваш слой бизнес логики это то же, что его (и Эванса) слой Application Layer (Service Layer). насколько я понял

Application Layer (...) coordinates tasks and delegates work to collaborations of domain objects in the next layer down.

domain objects — это модель.


а вот еще я не понял, что он имел-таки ввиду?:

There are cases when you make an argument for putting data source or presentation logic in a domain object, but that's orthogonal to my view of anemia.

Здравствуйте, Нахлобуч, Вы писали:

A>>Кстати по теме — мож кто в курсах как это делает ( и делает ли вообще ) NHibernate?

Н>It depends. Если с объектом работают в пределах одной сесси (ISession), то обновляться могут как все поля, так и только измененные -- это контролируется в маппингах (dynamic-update в class).
А можно здесь поподробнее?

Здравствуйте, Aviator, Вы писали:

A>А можно здесь поподробнее?

Извольте .

Вот начало маппинга:

<class name="Airport" table="Airport" lazy="true" dynamic-insert="true" dynamic-update="true" select-before-update="true">

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

class Airport : IBusinessObject
{
    public virtual long ID
    { get ... set ... }
    
    public virtual string RussianName
    { get ... set ... }
    
    public virtual string Code
    { get ... set ... }
}

при попытке сохранения объекта

Airport airport = new Airport("Домодедово", "DME");

будет сгенерирован SQL вида

insert into airport (russian_name, code) values (@russianName, @code)

А при вставке объекта

Airport airport = new Airport("Домодедово", null);

получится

insert into airport (russian_name) values (@russianName)

Для обновления аналогично: в

update airport set ...

попадут только измененные атрибуты.

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

Есть еще атрибут select-before-update, который влияет на поведение NH в случае, когда объект прицепили к новой ISession и пытаются сделать ему Update(), заставляя его (NH) выполнить select для того, чтобы понять действительно ли изменился этот объект, и если да, то что именно в нем поменялось. Накладные расходы тут очевидны, но у нас используется потому, что в доставшейся нам по наследству БД уйма триггеров, срабатывающих в самый неподходящий момент.

Здравствуйте, Нахлобуч, Вы писали:
Спасибо за разъяснение. А как NHibernate узнает, какие именно поля были изменены со времени последнего апдейта в рамках одной сессии?