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

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

G>>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей.

Z>Можно ссылку на выделенное?
Я ссылки не собираю. Можно посмотреть что тут пишут на форуме приверженцы жирной модели. Даже большой холивар был на эту тему.

G>> Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
G>>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.

Z>Мне кажется ты приписываешь DDD выдуманные недостатки, а потом их сокрушительно критикуешь.
Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.

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

G>Наведите порядок в терминологии. Есть части BL — business-rules — правила валидации модели и business-transactions — операции переводящие модель из одного состояния в другое.

Речь идёт слегка не о том: в поведении приложения есть грубо говоря два уровня ограничений: что оно может делать и что от приложения хочет заказчик. Возвращаясь к аналогии с авиаперевозчиком, полётные планы (а это не только ограничения, это куча муторной логики) должны быть зарегистрированы и соответствовать стандартам — это часть предметной области. Разумеется, работа с _конкретными_ планами (нюансы типа соответствия законодательству кучи стран) — это как раз бизнес логика.

Разница тут совсем неочевидна, но чем больше у вас разноплановых взаимодействующих систем, тем проще её увидеть.

---

G>А вот тут возникает самый нтересный вопрос: когда проверять business-rules.
Согласен. Сразу disclaimer — я говорю главным образом о толстых клиентах со statefull-логикой.

G>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.

Ну про DDD не надо. Эванс в первой части (когда он рассказывает что такое модель предметной области) нехило противоречит сам себе во второй (когда он начинает лепить всё в одну кучу).

Кстати, у нас локальная валидация на клиентах именно так и работает. Не всех ограничений конеш, а именно ограничений предметной области, их обычно немного. Да и то, это в основном не валидация пользовательского ввода (это к UI layer), а ассерты для поиска багов. Ещё я не совсем понял почему "проверки на каждый чих" — это признак Rich модели: эти проверки вполне могут быть оторваны от конкретного представления данных.

Скорее всего у нас просто разные предметные области — я первый убъюсь об стену если потребуется делать сложную валидацию на stateless аппсервере.

G>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.

А эти варианты не отменяют друг друга: проверка при сохранении обязательно должна быть и в идеале должна делаться силами СУБД.

---

G>Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям. Например самолет: хоть у него и конечная вместимость, но это имеет смысл только при операции погрузки.

Эххх... Я тоже так думал. А потом радостно убивался об стену. Чем больше систем работает с одними и теми же данными — тем больше коллизий.
Тут речь идёт даже не о загрузке самолёта, а о информации о конкретном рейсе. Эта информация используется при бронировании билетов (тут тоже целый цирк включая работу с турагенствами), уходит в отчёт что подаётся при регистрации вылета (сорри, терминологию сильно подзабыл, да и не специалист я, так, интересовался), ещё может понадобиться в налоговую/для отчётов и аналитики.

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

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

G>ЗЫ. Я еще не упоминул про busines-operations, которые состоят из множества business-transactions, возможо растянутых по времени.

Охх. Это отдельная тема. И так раздули.

P.S. Если я вас напрягаю — скажете, закруглимся

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

S>Если я нигде ничего не вру, там шла речь в контексте реализации UoW, да ещё и бизнес-процессы упоминались (мы говорим о его книжке "enterprise что-тотам"?).
Нет. Речь шла о его статье про антипаттерн Anemic Domain Model. (http://www.martinfowler.com/bliki/AnemicDomainModel.html)
Конкретно:

By pulling all the behavior out into services, however, you essentially end up with Transaction Scripts, and thus lose the advantages that the domain model can bring.

Правда дальше у него идет оговорочка

As I discussed in P of EAA, Domain Models aren't always the best tool.

Но он нигде не говорит, что же это за такие advantages, которые domain model can bring.

S>А ООП как ни странно немногое здесь может предложить, т.к. задача ближе к реализации workflow модели. Я говорю не реализации отдельных кирпичиков, а именно об управлении процессами.
А что за проблемы у ООП с управлением процессами?

S> И тут проблема о двух концах — либо у нас мегауниверсальные кирпичики, и трёхтомное "введение в конфигурацию для начинающих", либо кирпичики пишутся под задачи, но тогда уж не обижайтесь на "процедурное программирование".
Бррр... Собственно я с Фаулером не согласен прежде всего в том, что Anemic — это процедурное программирование. Он там еще пишет, что ОО-дизайн — это обязательно логика вместе с данными, так вот это полная пурга, как-то он очень узко и наивно ОО-дизайн представляет. Как только данные становятся персистентными, делать им вместе с логикой нечего — жизненный цикл разный, но при этом это ни на каплю не противоречит правильному ОО-дизайну.

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

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

G>>Наведите порядок в терминологии. Есть части BL — business-rules — правила валидации модели и business-transactions — операции переводящие модель из одного состояния в другое.

S>Речь идёт слегка не о том: в поведении приложения есть грубо говоря два уровня ограничений: что оно может делать и что от приложения хочет заказчик. Возвращаясь к аналогии с авиаперевозчиком, полётные планы (а это не только ограничения, это куча муторной логики) должны быть зарегистрированы и соответствовать стандартам — это часть предметной области. Разумеется, работа с _конкретными_ планами (нюансы типа соответствия законодательству кучи стран) — это как раз бизнес логика.
С точки зрения программы все равно откуда взялись требования — является ли это желанием заказчика или каким-либо законом.

S>Разница тут совсем неочевидна, но чем больше у вас разноплановых взаимодействующих систем, тем проще её увидеть.
Разницы на самом деле нету, она только в голове проектировщика.

S>

---

G>>А вот тут возникает самый нтересный вопрос: когда проверять business-rules.
S>Согласен. Сразу disclaimer — я говорю главным образом о толстых клиентах со statefull-логикой.
Такие случаи требуют отдельного рассотрения так как размазывание логики между клиентом и сервером создает дополнительные проблмемы, которые не связаны с постановкой задачи.
Я вообще склонен считать такие случаи паталогическими.

S>Кстати, у нас локальная валидация на клиентах именно так и работает. Не всех ограничений конеш, а именно ограничений предметной области, их обычно немного. Да и то, это в основном не валидация пользовательского ввода (это к UI layer), а ассерты для поиска багов.
Для поиска багов лучше тесты.

S>Ещё я не совсем понял почему "проверки на каждый чих" — это признак Rich модели: эти проверки вполне могут быть оторваны от конкретного представления данных.
Проверки на каждый чих избыточны. Реально необходима только одна проверка при сохранении данных. Для удобства пользователей делают дополнительные проверки.
Если же проверки засунты в объекты, то проверки будут именно на каждый чих.

S>Скорее всего у нас просто разные предметные области — я первый убъюсь об стену если потребуется делать сложную валидацию на stateless аппсервере.
От предметтной области мало зависит главное правильно разделить на business-rules и preconditions чтобы ничего лишнего не проверять.

G>>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
S>А эти варианты не отменяют друг друга: проверка при сохранении обязательно должна быть и в идеале должна делаться силами СУБД.
Как уже писал выше при наличии проверки при сохранении остальные проверки только для удобства.

S>

---

G>>Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям. Например самолет: хоть у него и конечная вместимость, но это имеет смысл только при операции погрузки.

S>Эххх... Я тоже так думал. А потом радостно убивался об стену. Чем больше систем работает с одними и теми же данными — тем больше коллизий. (*остальное опущено*)

Все что написано сильно зависит от предметной области и желаний заказчика.

Здравствуйте, IB!

IB>Нет. Речь шла о его статье про антипаттерн Anemic Domain Model. (http://www.martinfowler.com/bliki/AnemicDomainModel.html)
Ну вот — влез не с тем и не туда

S>>А ООП как ни странно немногое здесь может предложить, т.к. задача ближе к реализации workflow модели. Я говорю не реализации отдельных кирпичиков, а именно об управлении процессами.
IB>А что за проблемы у ООП с управлением процессами?
Эххх, мой кривой язык...
Проблемы не у ООП, а у товарищей что пытаются изобразить динамически конфигурируемый DSL силами ООП.


S>> И тут проблема о двух концах — либо у нас мегауниверсальные кирпичики, и трёхтомное "введение в конфигурацию для начинающих", либо кирпичики пишутся под задачи, но тогда уж не обижайтесь на "процедурное программирование".
IB>Бррр... Собственно я с Фаулером не согласен прежде всего в том, что Anemic — это процедурное программирование.
Да-да, тут вы меня поняли верно.

IB> Он там еще пишет, что ОО-дизайн — это обязательно логика вместе с данными, так вот это полная пурга, как-то он очень узко и наивно ОО-дизайн представляет. Как только данные становятся персистентными, делать им вместе с логикой нечего — жизненный цикл разный, но при этом это ни на каплю не противоречит правильному ОО-дизайну.
+5.

Закругляемся? // А то щас долго расшаркиваться будем какие мы оба хорошие...

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

G>С точки зрения программы все равно откуда взялись требования — является ли это желанием заказчика или каким-либо законом.
G>Разницы на самом деле нету, она только в голове проектировщика.

Щасс ответим — это вы хорошую тему подняли

Не обижайтесь, но у вас какое-то идеализированное представление о проектировании систем — берём требования, реализуем и все щасливы. Нифига!

• Во-первых требования никогда не содержат полной информации о предметной области. Это отдельная тема, подробнее стоит почитать у апологетов DDD.
  
• Во-вторых, требования заказчика не всегда бывают выполнимыми: их нужно прноверять.
  
• В-третьих если вам потребуется взаимодействие с внешними системами, от вас потребуется громадная куча фич, которые очевидны из предметной области, но не указаны в требованиях.
  
• В-четвёртых у модели предметной области приоритет банально выше: она стабильнее, требования заказчика гарантированно не могут выйти за пределы предметной области (точнее, могут захватить другую предметную область, но это другой разговор) и, самое главное, правила предметной области не зависят от хотелок заказчика/проектировщика и тем самым делает предсказуемым процесс разработки.

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

Разумеется, в жизни не всё так радужно, но если видите что я где-то не прав — давайте разберём по пунктам, ок?

---

G>Такие случаи требуют отдельного рассотрения так как размазывание логики между клиентом и сервером создает дополнительные проблмемы, которые не связаны с постановкой задачи.
G>Я вообще склонен считать такие случаи паталогическими.
G>Для поиска багов лучше тесты.

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

[ОФФТОП]
Про тесты: одно другого не отменяет. Лично мне куда проще саппортить такой код:

void SomeMethod(string arg1, params int[] indexes)
{
  Code.NotNullOrEmpty(arg1, "arg1");
  Code.NotNull(indexes, "indexes");
  Code.GreaterThenOrEqual(indexes.Length, "indexes.Length", 5);
  Code.AssertState(CanDoSomeOperation, @"Some detailed exception message");

  // code goes here
}

Сразу виден data contract + есть возможность отключать проверки по необходимости.
[/ОФФТОП]

G>Проверки на каждый чих избыточны. Реально необходима только одна проверка при сохранении данных. Для удобства пользователей делают дополнительные проверки.
G>Если же проверки засунты в объекты, то проверки будут именно на каждый чих.

Ну да, я примерно это и имел в виду: проверки при изменении в основном работают в UI layer и в основном для удобства пользователей. Ассерты — это так, дополнительная подстраховка, к тому же отключаемая.

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

G>Я ссылки не собираю. Можно посмотреть что тут пишут на форуме приверженцы жирной модели. Даже большой холивар был на эту тему.

Глядя на количество негативных постов про .net еще не пропало желание его использовать? Я вот регулярно натыкаюсь на ругательства по поводу быстродействия, GC, JIT и C# от людей которые только что вошли в технологию.

G>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал.

Чем он ужасен? Что мешает отказаться от него в случаях когда он приносит неудобства? Каким образом

G> Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.

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

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

Z>Чем он ужасен? Что мешает отказаться от него в случаях когда он приносит неудобства? Каким образом
он привязан к рич модели?

Z>IB написал не один пост, что DDDшными средствами вообще ничего делать нельзя. Его я и сам читаю, если лично у тебя есть аргументы по которым любое отображение информации надо делать неDDDшными средствами излагай.

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

GZ>>Organizes business logic by procedures where each procedure handles a single request from the presentation.
IB>Какое-то странное определение, ограничивающие Transaction Script презентацией, типа логики не может быть вообще.
+1
GZ>>Первое что бросается в глаза для Domain Model — both behavior and data. Чудненько и прекрасно. Очень похоже на Rich, если бы не абстрактный object model под которым можно понимать все что угодно.
IB>Это ты уже спекуляциями начинаешь заниматься — гаданием по Фаулеру, что же он имел ввиду.
Ну а что еще остается если изначально введеная им терминология неверна и алогична.

GZ>> Впрочем он никогда и не скрывал, что Anemic — это смесь Domain Model и Transaciton Script.
IB>Единственное что он говорил по этому поводу — "Какой кошмар, это же почти Transaction Script, это не ООП, а процедурное программирование" (С)
+1

GZ>>Я говорил именно об инстанцировании.
IB>А я об использовании.
Фраза вырванная из контекста — теряет смысл и может быть неверно истолкована.

GZ>>Смотря для кого?
IB>Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.
Ну а если не стоит его публиковать?

GZ>>Но оно инкапсулировано относитель BLL, и изолировано от слоя еще выше.
IB>Каким боком?
Ты не влезешь в базу данных напрямки. Только опосредовано интерфейсу.

GZ>>Инкапсуляция не может быть измерена.
IB>Инкапсуляция отлично меряется, что подробно расписано у того же Меерса.
Не знал о такой метрике. Интересно послушать как.

GZ>>Использовать ACLService.CanEdit мы никаким боком использовать не можем, поскольку для выдачи решения нам не хватает информации.
IB>Мы можем прекрасным образом использовать ACLService.CanEdit передав ему всю необходимую информацию — либо самого parent-а,
Либо проявив недюженные экстрансенсорные способности изначально записать в контракт идентификатор парента. Но это изменение границ проекта на итерации. За это неплохо и по шапке получить.
IB>либо построив бизнес объект таким образом, чтобы вся необходимая информация уже была в нем.
А тут мы убиваем некоторый бонус Anemic. Бизнес-объект в первоначальном варианте был не нужен. Его вполне можно было бы и не поднимать.

IB>Разница лишь в том, что в отличии от Rich ты сделаешь это явно, причем именно там где полагается — при обращении к ACL, а в случае Rich, спустя какое-то время ты будешь сильно удивляться — какого хрена при обращении к MyObj.CanEdit он еще и к родителю лезет.
Угу. Пункт 3 преимуществ Anemic

GZ>> В случае Rich — нам достаточно переделать реализацию CanEdit,
IB>В стройной модели тоже самое.
Противоречишь.

GZ>>Так что лезвие бритвы — инкапсуляция выше, ресурсоемкость тоже.
IB>Я думаю — ты уже понял, где ошибался? =)
Нет. Вот чего не понял, того не понял.

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

G>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
G>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
Никто не мешает совмещать. Простейшие проверки можно сделать в сеттерах — тогда они будут срабатывать еще и прямо при редактировании в гриде или прибинденных полях редактирования — что по моему скромному мнению есть очень удобно.
Более сложные проверки можно вынести либо в метод Validate либо в какой-то ValidationService().

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

Супер, я давно хотел такое написать, а то реально получаеться что толчеться вода в ступе.

Тока в конце написал бы что последнее вермя (не лет ) использую рич модель.

Кстати слегка коробит от термина "толстая модель"...

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

Z>IB написал не один пост, что DDDшными средствами вообще ничего делать нельзя.
Минуточку
Во-первых я про DDD вообще ни слова.
А во-вторых, я ни где не говорил что "нельзя", наоборот, можно все. Порой только диву даешься, какой причудливый код работает. Другое дело, что поддерживать и развивать такой код — вспотеешь.

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

MC>Супер, я давно хотел такое написать, а то реально получаеться что толчеться вода в ступе.
Только не Иван Иванычь, а Сергей Петрович, не пароход, а два рубля и не выиграл, а проиграл.
То есть, как выясняется — все напутано.

MC>Кстати слегка коробит от термина "толстая модель"...
Прально, потому что она жирная..

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

IB>>Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.
GZ>Ну а если не стоит его публиковать?
Рано или поздно все равно появится дополнительный сценарий, который потребует доступа к этому полю.

GZ>Ты не влезешь в базу данных напрямки. Только опосредовано интерфейсу.
Это всегда так, при любой модели.

GZ>Не знал о такой метрике. Интересно послушать как.
Почитай Меерса, в кратце — количество кода, которое потенциально может быть затронуто, при изменении объекта.

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

GZ>А тут мы убиваем некоторый бонус Anemic. Бизнес-объект в первоначальном варианте был не нужен. Его вполне можно было бы и не поднимать.
Нужен, ты же не одно поле поднимаешь.

GZ>Нет. Вот чего не понял, того не понял.
Стройная модель лучше, чем жирная, подходит для предложенного тобой изменения, а вовсе не наоборот.

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

IB>>>Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.
GZ>>Ну а если не стоит его публиковать?
IB>Рано или поздно все равно появится дополнительный сценарий, который потребует доступа к этому полю.
Могут появиться. А могут и не появиться. Зачем заниматься предварительной оптимизацией.

IB>Почитай Меерса, в кратце — количество кода, которое потенциально может быть затронуто, при изменении объекта.
Это не мера измерения. В основном измеряют цикломатическую сложность, coupling и cohesion. Для последних есть большое кол-во подвидов. Верная инкапсуляция, это всего лишь инструмент для оптимального coupling и cohesion.

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

GZ>>А тут мы убиваем некоторый бонус Anemic. Бизнес-объект в первоначальном варианте был не нужен. Его вполне можно было бы и не поднимать.
IB>Нужен, ты же не одно поле поднимаешь.
Почему? Если тебе для выполнения какого-то метода нужен только идентификатор, ты всегда отдаешь целый объект?

GZ>>Нет. Вот чего не понял, того не понял.
IB>Стройная модель лучше, чем жирная, подходит для предложенного тобой изменения, а вовсе не наоборот.
Опять?

+1
вот чего не хватает так это законченных примеров.
может в инете где-нить есть?

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

GZ>Могут появиться. А могут и не появиться. Зачем заниматься предварительной оптимизацией.
Она не предварительная.

GZ>Это не мера измерения.
А что же это?

GZ>В основном измеряют цикломатическую сложность, coupling и cohesion.
А не в основном?

GZ>Верная инкапсуляция, это всего лишь инструмент для оптимального coupling и cohesion.
Вот именно. Соответственно, если в случае одной инкапсуляции связность выше, значит инкапсуляция ниже, и наоборот.

GZ>Ну, о чем и говорилось. И соответвенно, как минимум во все методы вызывающие данный метод.
Это плохо? Еще раз — у тебя есть два варианта:
1. Изменить бизнес-объект таким образом, чтобы вся необходимая информация уже была в нем в момент вызова.
2. Явно передать всю необходимую информацию при вызове.
И оба эти варианта лучше чем неявное поднятие нового объекта в CanEdit
Собственно, есть и третий вариант — ты можешь проинжектить ACLService, сервисом работы с данными и опять-таки поднять неявно родительский объект в CanEdit, но так делать не стоит — это мало чем будет отличаться от жирной модели, просто лишний раз подтверждает, что стройная легко покрывает описанный тобой сценарий.

GZ>Почему? Если тебе для выполнения какого-то метода нужен только идентификатор, ты всегда отдаешь целый объект?
Я не про отдачу, а про то что в момент отдачи у тебя полюбому целый объект.

GZ>Опять?
Что опять?

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

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

MC>>Супер, я давно хотел такое написать, а то реально получаеться что толчеться вода в ступе.
IB>Только не Иван Иванычь, а Сергей Петрович, не пароход, а два рубля и не выиграл, а проиграл.
IB>То есть, как выясняется — все напутано.

Эм, ты щас про что?

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

S>+1
S>вот чего не хватает так это законченных примеров.
S>может в инете где-нить есть?

Все есть причем и того и того, достаточно подыскать опенсорсную реализацию чего-то и там копать...

Для рич моделей есть очень хороший специально сделаный пример — DDD Sample. Несмотря на то что это сампл, там покрыты 90% всех ситуаций стандарного корпоративного приложения.

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

MC>Эм, ты щас про что?
Про то что опысывая все это GlebZ, к сожалению много чего напутал и ясности не внес.