Заинтересовала статья: http://blogs.gotdotnet.ru/personal/bezzus/PermaLink.aspx?guid=7a6a69bd-bedf-425f-b09c-123b4a41f686

Кто что скажет?

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

QL>Заинтересовала статья: http://blogs.gotdotnet.ru/personal/bezzus/PermaLink.aspx?guid=7a6a69bd-bedf-425f-b09c-123b4a41f686
QL>Кто что скажет?
Статья правильная, хоть и написана несколько сумбурно. Больше похоже на стенограмму устного выступления, чем на журнальную статью. Ну, так это ж блог — "концерт в халате на лестничной клетке"

Очень интересная статья, задевает очень интересные темы.

Мне кажется, все зависит от того, что является отправной точкой. Если это Данные (БД), если данные нужно лишь представить пользователю, сортануть, фильтрануть и т.п., то конечно стройная модель вне конкуренции. Но если данные подлежать сложной обработке, расчетам, тут без объектов тяжело обойтись, сложную BL лучше всего в жирную модель паковать.

Как вообще может выглядеть архитекрура приложения в стройной модели. Как происходить расчленение на слои, какие они? Кинтье ссылки, тема очень интересная

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

А>Очень интересная статья, задевает очень интересные темы.

А>Мне кажется, все зависит от того, что является отправной точкой. Если это Данные (БД), если данные нужно лишь представить пользователю, сортануть, фильтрануть и т.п., то конечно стройная модель вне конкуренции. Но если данные подлежать сложной обработке, расчетам, тут без объектов тяжело обойтись, сложную BL лучше всего в жирную модель паковать.
В одной фразе сделано два несвязанных утверждения. Одно из них может быть верным, второе — крайне сомнительно.
Совершенно непонятно, чем мотивируется всовывание "сложной обработки" в жырную модель.
Поясняю на пальцах: вот есть у нас данные по продажам. Чек из магазина видели? "Сыр плав янт 0.406 132.70" и так далее? Он, понятное дело, печатается с компьютера, и всё это хранится в центральной БД.
Вот такой муйни — десятки миллионов строк. Всё повязано с датами, кредитными картами, и прочим. Аналитики годами придумывают алгоритмы сложной обработки, которые пытаются вытащить их этих кассовых чеков что-то полезное; типа трендов и корреляций.

Вниммание, вопрос: как назвать метод для построения возрастного тренда потребления товаров алкогольной группы, который мы вставим в класс OrderItem? А? Или этот метод будет в классе Order?
А ведь именно это и есть жирная модель.

А>Как вообще может выглядеть архитекрура приложения в стройной модели. Как происходить расчленение на слои, какие они?
Главным образом слой "алгоритмов" отделен от слоя данных, над которыми алгоритмы оперируют. При этом сами алгоритмы запросто могут быть полиморфными, параметризовываться друг другом и т.п. — то есть ООП на полную катушку. Не надо только их засовывать в данные.

Жирная модель в её крайнем проявлении — это вставка метода "взятие интеграла" в класс "Число". С перегрузками в классах "Целое число" и "Комплексное число".

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

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

А>>Очень интересная статья, задевает очень интересные темы.

А>>Мне кажется, все зависит от того, что является отправной точкой. Если это Данные (БД), если данные нужно лишь представить пользователю, сортануть, фильтрануть и т.п., то конечно стройная модель вне конкуренции. Но если данные подлежать сложной обработке, расчетам, тут без объектов тяжело обойтись, сложную BL лучше всего в жирную модель паковать.
S>В одной фразе сделано два несвязанных утверждения. Одно из них может быть верным, второе — крайне сомнительно.
S>Совершенно непонятно, чем мотивируется всовывание "сложной обработки" в жырную модель.
S>Поясняю на пальцах: вот есть у нас данные по продажам. Чек из магазина видели? "Сыр плав янт 0.406 132.70" и так далее? Он, понятное дело, печатается с компьютера, и всё это хранится в центральной БД.
S>Вот такой муйни — десятки миллионов строк. Всё повязано с датами, кредитными картами, и прочим. Аналитики годами придумывают алгоритмы сложной обработки, которые пытаются вытащить их этих кассовых чеков что-то полезное; типа трендов и корреляций.

S>Вниммание, вопрос: как назвать метод для построения возрастного тренда потребления товаров алкогольной группы, который мы вставим в класс OrderItem? А? Или этот метод будет в классе Order?
S>А ведь именно это и есть жирная модель.

А>>Как вообще может выглядеть архитекрура приложения в стройной модели. Как происходить расчленение на слои, какие они?
S>Главным образом слой "алгоритмов" отделен от слоя данных, над которыми алгоритмы оперируют. При этом сами алгоритмы запросто могут быть полиморфными, параметризовываться друг другом и т.п. — то есть ООП на полную катушку. Не надо только их засовывать в данные.

S>Жирная модель в её крайнем проявлении — это вставка метода "взятие интеграла" в класс "Число". С перегрузками в классах "Целое число" и "Комплексное число".

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

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

M>Ну и какой толк отделения данных от алгоритмов, если любое изменение данных должна по идее повлечь изменение алгоритмов.
Всё как раз наоборот.
Во-первых, как это вы собрались внести "любое изменение" в данные о продажах сети Wallmart с 1975 года?

Во-вторых, то, что вы называете "изменения данных", совершенно несущественно для большинства алгоритмов.

Ну вот, например, стали вы хранить не только ФИО менеджера, но и её девичью фамилию в уместных случаях.
Что, это как-то повлияет на алгоритм распределения заказов по менеджерам?

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

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

S>Всё как раз наоборот.
S>Во-первых, как это вы собрались внести "любое изменение" в данные о продажах сети Wallmart с 1975 года?

S>Во-вторых, то, что вы называете "изменения данных", совершенно несущественно для большинства алгоритмов.

S>Ну вот, например, стали вы хранить не только ФИО менеджера, но и её девичью фамилию в уместных случаях.
S>Что, это как-то повлияет на алгоритм распределения заказов по менеджерам?

Сейчас оспорю: ну, допустим, добавился какой-то там коэффициент, а наши алгоритмы забыли его применить. Результат — неверные расчеты. Мой аргумент — лишь для того что бы показать, что это может быть не всегда это хорошо. . (Зы: дискусию можете на эту тему не развивать, я хорошо понимаю указанные вами преимещества )

S>Да, в жырной модели вам придется напрячься как следует. Такое изменение — это форс-мажор, требующий немедленной перекомпиляции и замены всех клиентов, а в особо тяжких случаях умственных расстройств (см. тж. CRUD) — еще и апдейт большого ассортимента хранимых процедур.

Ну для этого есть хранимы процедуры

S>Анемичной модели всё равно, что там происходит с данными, которые ей не интересны. Мы по-прежнему можем скармливать в алгоритм объекты со старой структурой, благо стоимость поддержки каждого класса такой модели близка к нулю. Это провоцирует иметь достаточное разнообразие легковесных классов, вместо повторного использования небольшого набора тяжеловесных.

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

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

QL>Заинтересовала статья: http://blogs.gotdotnet.ru/personal/bezzus/PermaLink.aspx?guid=7a6a69bd-bedf-425f-b09c-123b4a41f686

QL>Кто что скажет?

Немного сумбурная. Больше всего повеселило, что сначала NHibernate представляется как монстр, который может использоваться только "жирную модель", а EF — провоцирует работать с данными "Стройном" стиле. Потом следует в общем-то правильные рассуждения, что "стройный" стиль удобнее. Основанные исключительно на примерах запросов к базе (про CRUD операции ничего нет). А потом делается вывод, что раз "жирный" стиль — это попсня и отстой — то отсутсвие поддрежки LazyLoad в EF это хорошо. Хотя по моему несколько не верная логическая цепочка.

Как всегдя подпись забыл. Я.

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

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

Ок, для алгоритма нам потребовались новые данные. Мы переписываем алгоритм, и только после этого затачиваем модель данных на предоставление информации. Если это вообще потребуется — потому, что коэффициент совершенно необязательно войдет в те же входные данные.

Давайте рассмотрим более реалистичный пример: начальник отдела ценообразования решил разрешать менеджерам указывать скидку на конкретные позиции на свое усмотрение. При этом можно делать разную скидку разным позициям.
В толстой модели это дупа: расчет цены позиции вшит в класс OrderItem, теперь его надо поменять. В классе Order у нас был расчет скидки на весь заказ, на основе данных клиента, его нужно не забыть выкинуть, иначе скидка посчитается два раза. Куча кода, завязанного на то, что в позции хранится сумма без скидки, поползет.

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

Главное — не думать об этом в терминах "о, мы добавили в класс OrderItem коэффициент скидки, что теперь делать?".

M>Ну для этого есть хранимы процедуры
Для чего? Для того, чтобы расширение базы не сводилось к alter table add column, а еще и требовалось пересоздать все процедуры типа Create_Manager?

M>Вообще интересует архитектруа. Вообще меня интересует архитектура, получается, если мы используем только легкие классы, то слой Бизнес логики уже не предоставляет интереса, и последующим классом сервиса, который этот слой обрабатывает и отдает результаты наверх.
У меня сбой парсинга набора слов. Что хотелось узнать?
M>Все выборки и обработки можно делать в предствениях. Или? Хочу живой пример , проект
У меня — нету живого примера. Я проектированием Enterprize приложений давно уже не занимаюсь. Может, IB что подкинет.

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

S> Больше похоже на стенограмму устного выступления, чем на журнальную статью. Ну, так это ж блог — "концерт в халате на лестничной клетке"
Ну так и писалось. Просто хотелось все тезисы того флейма в одно место сложить.. =)

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

V>Больше всего повеселило, что сначала NHibernate представляется как монстр, который может использоваться только "жирную модель", а EF — провоцирует работать с данными "Стройном" стиле.
Блин, ну не там такого. Оно, конечно, сумбурно, но конкретно про гибернейт в этом сумбуре нет ни слова.
Там есть "мнение авторов NHibernate" (c). Авторы NH выступают за жирный стиль, и обвиняют EF в провокации стройного. Все.
Там написано только это и ничего более. Еще раз повторюсь, я не настоящий сварщик и мотоцикл не мой, это позиция авторов NH, на которую я описаюсь в своих рассуждениях.

V>Хотя по моему несколько не верная логическая цепочка.
Там совсем другая логическая цепочка.

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

V> Больше всего повеселило, что сначала NHibernate представляется как монстр, который может использоваться только "жирную модель", а EF — провоцирует работать с данными "Стройном" стиле.
Специально цитата из комментариев, еще раз:
На всякий случай, еще раз проясню свою позицию, чтобы она дошла до самых отдаленных уголков мозга внимательных читателей...
Я специально старался нигде не затронуть ни NH, ни любой другой ORM инструмент, чтобы не ввязываться в бесполезные религиозные споры. Я лишь констатировал тот факт, что _разработички_ NH являются сторонниками "жирной" модели. О чем недвусмысленно заявлено в их манифесте: "The Entity Framework encourages the Anemic Domain Model anti-pattern by discouraging the inclusion of business logic in the entity classes".
В отличии от них, я считаю антипаттерном именно Rich модель, а Anemic, как раз очень правильным паттерном. Почему я так считаю, я и описал в данной статье.
Я вполне допускаю, что мнение разработчиков NH может не совпадать с возможностями инструмента, который у них получился. Возможности NH — совершенно отдельный вопрос, который на данный момент мне вообще мало интересен.

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

S>> Больше похоже на стенограмму устного выступления, чем на журнальную статью. Ну, так это ж блог — "концерт в халате на лестничной клетке"
IB>Ну так и писалось. Просто хотелось все тезисы того флейма в одно место сложить.. =)

То-то я и думаю, где-то я это всё уже читал. Хотел даже автора в плагиатстве упрекнуть

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

QL>Кто что скажет?

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

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

S>Здравствуйте, Mmmaloy, Вы писали:
S>Это крайне странно.
S>В моей виртуальной реальности первично именно изменение алгоритма. Например, речь идет о начислении налога на транспортные средства по обновленному законодательству. Или о расчете задолженности по неиспользованному отпуску, которую вообще пересматривают раз в два года.

В моей реальности тоже алгоритм и его изменения первичны. Но у меня есть шеф. ТЧК. Его эти алгоритмы не интересуют, или точнее стоят на втором месте. В первую очередь его интересуют данные, которые лежат в базе. Данные которые там лежат — это сердце,от них идет вся остальная пляска. Обработка данных довольно сложная. И ее предствление может меняться (в принципе не новость). В его интресах реализовать все по максимуму быстро и просто, задействовав лишь средства представляемые языком (c#) и его стандартными библиотеками. При этом он застявляет меня отказаться от объектов, другими словами от жирной модели (которую я, не так давно-то освоил, но она меня удовлетворяет, вроде бы все складно получается, да и с объектами мне как-то проще работать). Взамен предлагает вытаскивать данные в DataSet, из него XML-представление DataSet и с помощью xslt проецировать данные в новые Xml, которые представляются (юзер интрефейс). Как в таком приложении распределить наилучшим способом слои, логику ума неприложу. Ведь данные нужно еще редактировать, валидировать. А тут эта статься подвернулась, ну думаю "АГА! Вот кажется то что впишется и в мое понятие и понятие начальника (его понятие исключает ООП)". В принципе, насколько я его понял, его интересует как я понимаю, его то и интересует стройная модель, но как к этому подойти незнаю.

S>Ок, для алгоритма нам потребовались новые данные. Мы переписываем алгоритм, и только после этого затачиваем модель данных на предоставление информации. Если это вообще потребуется — потому, что коэффициент совершенно необязательно войдет в те же входные данные.

S>Давайте рассмотрим более реалистичный пример: начальник отдела ценообразования решил разрешать менеджерам указывать скидку на конкретные позиции на свое усмотрение. При этом можно делать разную скидку разным позициям.
S>В толстой модели это дупа: расчет цены позиции вшит в класс OrderItem, теперь его надо поменять. В классе Order у нас был расчет скидки на весь заказ, на основе данных клиента, его нужно не забыть выкинуть, иначе скидка посчитается два раза. Куча кода, завязанного на то, что в позции хранится сумма без скидки, поползет.

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

S>В анемичной модели у нас код расчета скидок отделен от кода представления заказов. Мы точно знаем, где и что нужно менять. Более того, мы можем полиморфно выбирать алгоритм расчета скидок в зависимости от, к примеру, даты создания заказа. Чтобы задним числом ничего не пересчитывать.

S>Главное — не думать об этом в терминах "о, мы добавили в класс OrderItem коэффициент скидки, что теперь делать?".

M>>Вообще интересует архитектруа. Вообще меня интересует архитектура, получается, если мы используем только легкие классы, то слой Бизнес логики уже не предоставляет интереса, и последующим классом сервиса, который этот слой обрабатывает и отдает результаты наверх.
S>У меня сбой парсинга набора слов. Что хотелось узнать?
M>>Все выборки и обработки можно делать в предствениях. Или? Хочу живой пример , проект
S>У меня — нету живого примера. Я проектированием Enterprize приложений давно уже не занимаюсь. Может, IB что подкинет.

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

Еще раз ко всем — вот бы живой проектик для изучения.

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

M>В моей реальности тоже алгоритм и его изменения первичны. Но у меня есть шеф. ТЧК. Его эти алгоритмы не интересуют, или точнее стоят на втором месте.
Вы просто плохо понимаете, о чем вам толкует шеф.
M>В первую очередь его интересуют данные, которые лежат в базе. Данные которые там лежат — это сердце,от них идет вся остальная пляска.
Совершенно верно. И я слабо себе представляю, по какой причине структура этого сердца может самопроизвольно изменится. Да еще и так, что алгоритмы потребуется "подгонять" под нее.
M>Обработка данных довольно сложная. И ее предствление может меняться (в принципе не новость). В его интресах реализовать все по максимуму быстро и просто, задействовав лишь средства представляемые языком (c#) и его стандартными библиотеками. При этом он застявляет меня отказаться от объектов, другими словами от жирной модели (которую я, не так давно-то освоил, но она меня удовлетворяет, вроде бы все складно получается, да и с объектами мне как-то проще работать).
По-прежнему через запятую перечисляются совершенно ортогональные вещи. Работайте с объектами — кто вам запрещает? DataSet — это объект. XsltTransform — тоже объект. В чем проблема?

M>Взамен предлагает вытаскивать данные в DataSet, из него XML-представление DataSet и с помощью xslt проецировать данные в новые Xml, которые представляются (юзер интрефейс).
Это, конечно, не единственный способ построить MVP архитектуру, но в принципе вполне жизнеспособный. Поясняю: в этом подходе данные достаются из SQL сервера за один (1) прием. Есть гарантия того, что никакая ленивая зараза не потащит какой-то хвост из базы в момент, когда уже Render поехал. Далее, нет никакого кэша объектов, который живет своей жизнью, жрет память и требует синхронизации. Всё, мы датасет забрали, теперь можно отпустить SQL сервер заниматься другой полезной работой. Импульсный режим для серверов — это самый сенокос.

Теперь у нас, значит, поехала трансформация. В чем начальник прав? С тем, что редкий databound контрол в aspx сравнится по скорострельности отплевывания форматированного аутпута со старым добрым откомпилированным XSLT. Я надеюсь, все в курсе, что текстовый XSLT сначала парсится, потом по нему генерируется MSIL код, который затем обрабатывается джитом, и в итоге мы имеем самый что ни на есть нативный код, который шарашит по твоему XML как казак по степи?

M>Как в таком приложении распределить наилучшим способом слои, логику ума неприложу.
Ну, всё зависит от того, какие именно трансформации надо делать. Если данные подготовлены в приемлемом виде, то, скорее всего, двухстадийной конверсии вполне хватит. Слой номер 1 будет отвечать за перекладывание данных в представление, эквивалентное по структуре целевому layout, а слой номер 2 будет отвечать за применение визуальных стилей и вообще конверсию каркаса layout в конечный HTML.

M>Ведь данные нужно еще редактировать, валидировать.
Я так понял, что редактирование данных в вашем случае — редкая и малонужная экзотика. Сложными являются алгоритмы обработки, так? Если не так, то нужно понимать, что
а) вводиться должны не те данные, которые удобно обрабатывать и хранить, а те, которые удобно вводить. Нет ничего хуже для UI, чем generic grid и generic edit form. Введенные данные должны как-то обработаться и лечь в базу.
б) валидацию данных крайне вредно проводить в классах самих данных. Дело в том, что правила валидации почти никогда не бывают настолько жесткими, как модель ООП. Это скорее рекомендации, или пожелания. Вам сказали, что в почтовом индексе могут быть только цифры? Забудьте, Австралия и Англия используют буквы с цифрами. Если вы держите код валидации отдельно от данных, вам чинить такие проблемы легко и приятно. Более того, вам не нужен экземпляр класса "Покупатель" для того, чтобы проверить ввденный индекс на корректность. За это отвечает какой-то ZipFieldValidator, который никак не связан с domain model.

M>А тут эта статься подвернулась, ну думаю "АГА! Вот кажется то что впишется и в мое понятие и понятие начальника (его понятие исключает ООП)". В принципе, насколько я его понял, его интересует как я понимаю, его то и интересует стройная модель, но как к этому подойти незнаю.

SM>Здесь опять куча утверждений, я прекрасно обхожусь с объектами и данными в них,
Мы говорим не о данных в объектах, а о логике в этих объектах.

M>Извиняюсь за изложение мыслей, фактор времени давил, не сформировал до конца. Попробую еще раз. Было указанно о полезности легковесных классов, которые содержат только ту логику (алгоритмы), которая нужна, данные здесь в стороне.
Еще раз, на пальцах: легковесные классы в анемичной модели никакой логики не содержат. Это просто контейнеры для данных.
M>Было интересно какое место эти алгоритмы займут в архитектуре приложения.
"Эти" — это какие? Поймите, ООП — это про поведение. У данных никакого поведения нет. Это не "заказ" выбирает себе "менеджера", и не "менеджер" захватывает себе заказ. Поведение есть у системы: OrderProcessingService назначает менеджера для нового заказа. Причем он запросто при этом может пользоваться ManagerSelectionService для того, чтобы абстрагироваться от алгоритма поиска подходящего менеджера.
Вы про эти алгоритмы говорите?

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

S>Вниммание, вопрос: как назвать метод для построения возрастного тренда потребления товаров алкогольной группы, который мы вставим в класс OrderItem? А? Или этот метод будет в классе Order?
S>А ведь именно это и есть жирная модель.
Антон, это жирная модель наивысшей степени ожирения.

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

---

Я не буду озвучивать свою текущую позицию (кроме того, что она является светло-светло-черной (anemic-anemic-rich model)). Ибо знаю, что сейчас пойдет спор на много постов, в итоге которого каждый останется при своем мнении либо же все придем к единому, но разобраться в том "как это было" будет невозможно.


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

Поэтому остановимся на конкретном примере (из моего текущего проекта):
Система управления проектами. Ключевая сущность -- Проект. На проекте находятся люди (Participants). У проекта есть проджект лид (PL) и человек отвечающий за текущий этап работ 'Assigned To' (AT).

Бизнесс требования (те что есть у нас сейчас):
1) AT и PL может быть назначен любой пользователь системы.
2) При изменении AT либо PL на другого пользователья, старый должен оставаться в проекте.
3) AT и PL не могут быть удалены из пользователей проекта.


Как реализовывать эти требования в Rich модели я знаю. Работать с полученным классом будет удобно. А вот как сделать то же самое (сохранив удобство) в анемичном стиле... ума не приложу.


СУВ, Андрей

P.S. Еще желательно держать в уме требование ведения истории изменений в проекте. Как только разберемся с AT/PL рассмотрим его (ибо я совсем не понимаю как его удобно реализовать в анемичной модели).

Спрева слова благодарности, что теряешь со мной время.

M>>Обработка данных довольно сложная. И ее предствление может меняться (в принципе не новость). В его интресах реализовать все по максимуму быстро и просто, задействовав лишь средства представляемые языком (c#) и его стандартными библиотеками. При этом он застявляет меня отказаться от объектов, другими словами от жирной модели (которую я, не так давно-то освоил, но она меня удовлетворяет, вроде бы все складно получается, да и с объектами мне как-то проще работать).
S>По-прежнему через запятую перечисляются совершенно ортогональные вещи. Работайте с объектами — кто вам запрещает? DataSet — это объект. XsltTransform — тоже объект. В чем проблема?

Запрещается наследоваться что бы расширить функционал, запрещается агрегация что бы скрыть лишние свойсвтва объектов, все должно быть по возможности размазано во одном классе. Наследование запрещено вообще. Приложение состоит из минимального количества классов. Даже при работе с XML никаких оберток-классов — если нужны данные, вытаскиваем их по XPAth и все. Конечно из этого всего получается довольно сложная вермишель. Это я имел ввиду.

M>>Взамен предлагает вытаскивать данные в DataSet, из него XML-представление DataSet и с помощью xslt проецировать данные в новые Xml, которые представляются (юзер интрефейс).
S>Это, конечно, не единственный способ построить MVP архитектуру, но в принципе вполне жизнеспособный. Поясняю: в этом подходе данные достаются из SQL сервера за один (1) прием. Есть гарантия того, что никакая ленивая зараза не потащит какой-то хвост из базы в момент, когда уже Render поехал. Далее, нет никакого кэша объектов, который живет своей жизнью, жрет память и требует синхронизации. Всё, мы датасет забрали, теперь можно отпустить SQL сервер заниматься другой полезной работой. Импульсный режим для серверов — это самый сенокос.

Но объем данных впечатляет, я попытался сгенерить студией типизировнный DataSet только лишь для небольшой кучки таблиц из базы, сгенерированный код занимал больше 30 мегабайт. Вообще-то я думал, что память жрет как раз такой DataSet, синхронизации от тоже требует.
Преимещество датасета шеф называет автоматическое создание XSD, т.е. автоматическая валидация данных. Но по мне так, эта не та валидация, которая может быть представлена пользователю. А уж если данные проскочили через валидацию UI, то это БАГ, Exception, который нужно будет исправлять. Так накой мне этот XSD?

S>Теперь у нас, значит, поехала трансформация. В чем начальник прав? С тем, что редкий databound контрол в aspx сравнится по скорострельности отплевывания форматированного аутпута со старым добрым откомпилированным XSLT. Я надеюсь, все в курсе, что текстовый XSLT сначала парсится, потом по нему генерируется MSIL код, который затем обрабатывается джитом, и в итоге мы имеем самый что ни на есть нативный код, который шарашит по твоему XML как казак по степи?

Вообще-то это WPF-приложение, где биндинг должен будет осуществлятся к XmlDataProvider. Achtung!!! Даже не ObjectDataProvider! XMLDataProvider — который будет содержать Xml сгенерированный поле XMLT преобразований XML из DataSet.

M>>Ведь данные нужно еще редактировать, валидировать.
S>Я так понял, что редактирование данных в вашем случае — редкая и малонужная экзотика. Сложными являются алгоритмы обработки, так? Если не так, то нужно понимать, что

Нет не так. Данные обрабатываются, изменяются, добавляются, вычисляются.
Если бы речь шла о статических данных (например — репортинг) не было бы речи

S>а) вводиться должны не те данные, которые удобно обрабатывать и хранить, а те, которые удобно вводить. Нет ничего хуже для UI, чем generic grid и generic edit form. Введенные данные должны как-то обработаться и лечь в базу.
S>б) валидацию данных крайне вредно проводить в классах самих данных. Дело в том, что правила валидации почти никогда не бывают настолько жесткими, как модель ООП. Это скорее рекомендации, или пожелания. Вам сказали, что в почтовом индексе могут быть только цифры? Забудьте, Австралия и Англия используют буквы с цифрами. Если вы держите код валидации отдельно от данных, вам чинить такие проблемы легко и приятно. Более того, вам не нужен экземпляр класса "Покупатель" для того, чтобы проверить ввденный индекс на корректность. За это отвечает какой-то ZipFieldValidator, который никак не связан с domain model.

Хорошее замечание. учту.

SM>>Здесь опять куча утверждений, я прекрасно обхожусь с объектами и данными в них,
S>Мы говорим не о данных в объектах, а о логике в этих объектах.

M>>Извиняюсь за изложение мыслей, фактор времени давил, не сформировал до конца. Попробую еще раз. Было указанно о полезности легковесных классов, которые содержат только ту логику (алгоритмы), которая нужна, данные здесь в стороне.
S>Еще раз, на пальцах: легковесные классы в анемичной модели никакой логики не содержат. Это просто контейнеры для данных.
M>>Было интересно какое место эти алгоритмы займут в архитектуре приложения.
S>"Эти" — это какие? Поймите, ООП — это про поведение. У данных никакого поведения нет. Это не "заказ" выбирает себе "менеджера", и не "менеджер" захватывает себе заказ. Поведение есть у системы: OrderProcessingService назначает менеджера для нового заказа. Причем он запросто при этом может пользоваться ManagerSelectionService для того, чтобы абстрагироваться от алгоритма поиска подходящего менеджера.
S>Вы про эти алгоритмы говорите?

Вот как я понимаю: Есть легкий класс данных — одни поля, эти данные могут полным отображением таблицы, могут быть ее частью или объединением нескольких таблиц. Как здесь представляются связи типа один ко многим? вероятно тоже коллекции этих классов. Класс их обрабатывающий (алгоритмы) по сути должен агригировать этот легкий класс (даже упомянтуй вами способ с ManagerSelectionService, на мой взгляд, подрузамевает эту агрегацию, ваш сервис лишь подбират менеджера, который должен эти данные агрегировать). Если не пользоваться никакими дополнительными средствами (типа Linq или Entity Framework), кто знает о внутренней структуре данных, что бы мочь их сохранять или грузить? Для класса с логикой это было бы слишком много, знать как сохранять данные (работать с БД) и их же обрабатывать (абстрагируясь от BD). Получается, что как минимум работу с БД (операции сохранения, чтения) должны быть реализованны в Классах с данными (может быть не напрямую, а используя еще один слой — например шлюз). Но я опять получил ту же объектную модель.
В общем у меня пока не сходится, как использовать стройную модель.

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

M>Спрева слова благодарности, что теряешь со мной время.


M>Запрещается наследоваться что бы расширить функционал, запрещается агрегация что бы скрыть лишние свойсвтва объектов, все должно быть по возможности размазано во одном классе.
От чего запрещено наследоваться?
M> Наследование запрещено вообще. Приложение состоит из минимального количества классов.
M>Даже при работе с XML никаких оберток-классов — если нужны данные, вытаскиваем их по XPAth и все. Конечно из этого всего получается довольно сложная вермишель. Это я имел ввиду.
Ну, вообще-то XPath относительно легко поправить в случае изменения структуры XML, в отличие от кода, который бегает по классам-оберткам.
Главный вопрос, который хочется себе задать: а эти классы-обёртки — они для чего?

M>Но объем данных впечатляет, я попытался сгенерить студией типизировнный DataSet только лишь для небольшой кучки таблиц из базы, сгенерированный код занимал больше 30 мегабайт. Вообще-то я думал, что память жрет как раз такой DataSet, синхронизации от тоже требует.
А зачем тебе типизированный? Для генерации XML вполне сойдет и нетипизированный.
M>Преимещество датасета шеф называет автоматическое создание XSD, т.е. автоматическая валидация данных. Но по мне так, эта не та валидация, которая может быть представлена пользователю. А уж если данные проскочили через валидацию UI, то это БАГ, Exception, который нужно будет исправлять. Так накой мне этот XSD?
Про XSD я мысль шефа не понял — рядом калорифер включен, шумит зараза в телепатическом диапазоне.

M>Вообще-то это WPF-приложение, где биндинг должен будет осуществлятся к XmlDataProvider. Achtung!!! Даже не ObjectDataProvider! XMLDataProvider — который будет содержать Xml сгенерированный поле XMLT преобразований XML из DataSet.
А в чем собственно ахтунг? Ты же не ожидаешь от ObjectDataProvider каких-то чудес в духе Дэвида Блейна?

M>Нет не так. Данные обрабатываются, изменяются, добавляются, вычисляются.
Я не о данных, а об UI. Как выглядит надводная часть айсберга? Мой любимый пример — данные о продажах. Весь Input UI — одна (1) форма ввода чека.
Зато вот отчетов на этом придумано столько, что оторопеть можно.
У тебя сколько use-case для ввода, и сколько use-case для вывода?


M>Вот как я понимаю: Есть легкий класс данных — одни поля, эти данные могут полным отображением таблицы, могут быть ее частью или объединением нескольких таблиц.
Совершенно верно.
M>Как здесь представляются связи типа один ко многим?
Непонятно, нужны ли здесь такие связи вообще. 90% алгоритмов хотят на вход однородный список неких структур. Очень-очень редко нам захочется прицепить к каждому элементу этого списка некую коллекцию (например, OrderItems к Order)

M>вероятно тоже коллекции этих классов. Класс их обрабатывающий (алгоритмы) по сути должен агригировать этот легкий класс (даже упомянтуй вами способ с ManagerSelectionService, на мой взгляд, подрузамевает эту агрегацию, ваш сервис лишь подбират менеджера, который должен эти данные агрегировать).
Продолжаю непонимать смысл слова "агрегировать" в данном контексте. Класс ManagerSelectionService вообще может быть Stateless, и никого не агрегировать.

M>Если не пользоваться никакими дополнительными средствами (типа Linq или Entity Framework), кто знает о внутренней структуре данных, что бы мочь их сохранять или грузить?
Сохранять или грузить — это самое легкое. Этим как раз может и должна заниматься инфраструктура Lightweight ORM.

M>Для класса с логикой это было бы слишком много, знать как сохранять данные (работать с БД) и их же обрабатывать (абстрагируясь от BD). Получается, что как минимум работу с БД (операции сохранения, чтения) должны быть реализованны в Классах с данными (может быть не напрямую, а используя еще один слой — например шлюз). Но я опять получил ту же объектную модель.
Нет, зачем нам это в классах с данными?
Идея примерно такая:
1. Есть технический код, который умеет доставать из базы произвольные данные и складывать их в произвольные объекты (например, NHibernate, Linq2Sql, или BLToolkit)
2. Есть совершенно ортогональная этому коду и бизнес логике анемичная модель. В продвинутых случаях далеко не все из классов этой модели вообще получат собственные имена.
3. Есть построенный на основе этого кода слой доступа к БД, специфичный для твоей модели данных. Он работает с объектами классов модели, описанной в п.2.
3. Есть слой бизнес-логики, который пользуется слоем доступа к БД.
Примернно так.
M>В общем у меня пока не сходится, как использовать стройную модель.

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

A>Вот Иван противопоставляет стройную модель жирной: чистые контейнеры данных -- супер пупер навороченым "сам-самычам" (все делают сами).
A>Опять спор белого и черного? А как же светло-черный, темно-белый, серый наконец? Существует же огромное количество промежуточных цветов.
A>Зачем все возводить в абсолют? Если стройная, то аннорексия, если жирная, то высшая степень ожирения

Ну, мы же в форуме. Здесь без абсолюта никак
A>

---

A>Давайте развернем дискуссию. Начнем с конкретной реализации, а только потом займемся идеями лежащими в основе.

A>Поэтому остановимся на конкретном примере (из моего текущего проекта):
A>Система управления проектами. Ключевая сущность -- Проект. На проекте находятся люди (Participants). У проекта есть проджект лид (PL) и человек отвечающий за текущий этап работ 'Assigned To' (AT).

A>Бизнесс требования (те что есть у нас сейчас):
A>1) AT и PL может быть назначен любой пользователь системы.
A>2) При изменении AT либо PL на другого пользователья, старый должен оставаться в проекте.
A>3) AT и PL не могут быть удалены из пользователей проекта.


A>Как реализовывать эти требования в Rich модели я знаю. Работать с полученным классом будет удобно. А вот как сделать то же самое (сохранив удобство) в анемичном стиле... ума не приложу.
Я не очень понимаю, в чем основное удобство.
Я не очень понимаю, в чем проблема сделать stateless класс ProjectManagement, который хэндлит все ситуации:

public interface IProjectManagement
{
  void SetProjectLead(Project project, ParticipantId lead);
    void AssignProject(Project project, ParticipantId assignee);
    void AddParticipant(Project project, ParticipantId participant);
    void RemoveParticipant(Project project, ParticipantId participant);
}

Ну да, у всех методов первый аргумент получился Project. Но фишка в том, что ты можешь поменять этот класс, не меняя модели данных — например, сделать так, чтобы проверялось отсутствие двойных назначений сотрудников, или отсутствие тройных назначений, или еще что-нибудь. Или, например, можно сделать так, чтобы удаление ProjectLead с проекта было не запрещено, а вместо него автоназначался его заместитель.