автор Вся логика (как я понимаю это бизнес логика) должна быть в Model! Model - это не только классы-объекты, которые генерируются EF/WCF или еще чем, а это вся бизнес логика, и даже сервисы и т.п.



Это только в русской wiki должна быть вся бизнес-логика(специально посмотрел). В английском
авторA domain model, or Domain Object Model (DOM) in problem solving and software engineering can be thought of as a conceptual model of a domain of interest (often referred to as a problem domain) which describes the various entities, their attributes and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain

Помимо этого есть масса других подходов для борьбы с бизнес-объектами(ActiveRecords, D в периоде, еtc), но ни в одном не было и не будет всей логики в силу нарушения тех принципов, которые ты упоминал в тезисах. Помимо этого бизнес-требования могут существенно меняться однако это совершенно не означает изменения структуры БД и соответствующих БО

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

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

Самопальный вариант борьбы с данными, как я понял, все дружно забраковали.
Дальше у каждого свои предпочтения(RIA, EF, список можно продолжить до бесконечности).
Нивелировать весь этот зоопарк можно с помощью паттерна Repository(приблизительный вариант я уже показывал). В нем скрываем детали реализации получения данных, а Model задает структуру бизнес-объектов и содержит только валидацию для обеспечения консистентности данных. Таким образом можно перейти с двухзвенки на 3х, не зависеть от метода вызовов(синхронный или асинхронный), обеспечить при необхомости кэширование и тд не меняя всего остального.

Обсуждаем, затем продолжаем...

iscrafmiТема интересная и можно ее продолжить без уважаемого MVP(он и в блоге тоже предпочитает вопросы переводить в личку и не хочет нести знания в массы, соответствуя своему статусу).

облажаться просто более ущербно. Все проще. А тема действительно интересная

Возможно. Он уже опубликовал свой вариант на Codeproject .

Детально не смотрел, но:

- Model содержит команды, о переносимости, на которую указывал MCУ(ASP,WPF\SL,Winforms, etc), сразу можно забыть.
- Конструктор содержит правила валидации - лишние тормоза в случае, когда правила валидации применимы ко всему типу объекта
- валидация через аттрибуты влечет необходимость изменения модели при изменении соответствующих правил. Постоянный Reflection для них


- Сложно и накладно. Можно в сеттере свойства сразу делать проверки без всяких делегатов и подписок. Это позволит обойтись полностью без UpdateSourceTriggerHelper

- DelegeteCommand без слабых ссылок, как мы давно уже знаем, возможны утечки памяти

ЗЫ Любим мы избретать все самостоятельно.

Denis Gladkikhi- Model содержит команды, о переносимости, на которую указывал MCУ(ASP,WPF\SL,Winforms, etc), сразу можно забыть.
Я смотрю вы все приложения с таким расчетом разрабатываете? Что завтра Silverlight перенесете на ASP.NET? Глупости не говорите, когда стоит задача разработки приложения на несколько платформ, тогда и совершенно другой подход работает. Притом, я смотрю, вы гражданин раньше любитель MVVM теперь против использования команд? Это пять.

i- Конструктор содержит правила валидации - лишние тормоза в случае, когда правила валидации применимы ко всему типу объекта
Феерический бред. Я понимаю, что хочется придраться к чему-нибудь. Но вот эта фраза ставит все на свои места.

i- валидация через аттрибуты влечет необходимость изменения модели при изменении соответствующих правил. Постоянный Reflection для них
Тут, я думаю, может понять только автор, что же он хотел сказать. И я смотрю идет постоянная путаница между моделью (Model) и моделью представления (ViewModel), ну это ладно. Спрашивается, а есть такая волшебная валидация, которая не требует изменения при изменении правил?

i- DelegeteCommand без слабых ссылок, как мы давно уже знаем, возможны утечки памяти
А тут вот действительно интересно, а слабо показать? ;) Один пример: запихни туда 1000 кнопок, пересоздавай для них ViewModel, переноси ViewModel от одной кнопки к другой, ну и все в том же духе. Покажи, что в этом случае будет утечка, уж очень интересно. Я понимаю прочли одну умную статью про WeakReference, но все же нужно уметь применять в нужных местах. А еще возможен конец света в 2012, ждете?

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

МСУМда... Пихать в модель валидацию - тут не только кросспереносимость пойдёт лесом, но и в текущем приложении возможны грабли: для редких, но реальных случаев, когда одна и та же модель в разных представлениях может немного отличаться поведением. Классический пример - пользователь и администратор (ролевые политики). Их GUI может различно вести себя в разрезе валидации и определенных этих политик безопасности.
Так что за такой родход имеет право на жизнь в хеллоуворлд софте.
Проблема решается очень легко на любой реализации. Если тяжко додуматься как, у вас проблемы.

P.S. Уважаемый, МСУ, я вас попросил не обращаться ко мне подобный образом, так как вы игнорируете, я понимаю, что вы просто не хотите относится ко мне, как к оппоненту, с уважением. Пускай так, ваше право.

Денис, рано тебе отвечать на вопросы и публиковать статьи. Ты еще находишься в пионерском периоде, когда изобретаются собственные велосипеды без всякого опыта, да и в теории большие проблемы.
Для работы с БД есть большое кол-во фреймворков, которые применимы для всей линейки Net, c валидацией и реализацией всех интерфейсов(в том числе и разграничением доступа,MCУ), которые нужны для клиентской части.
В них нет такого "феерического бреда"(буду придерживаться твоей терминологии), который ведет к большим накладным расходам и тормозам, как пообъектная валидация, когда она применима ко всему типу(длина строки,not null,etc) или DelegeteCommand в Model(посмотри ее реализацию в Prism, там же на форуме есть обсуждение утечек памяти из-за кривости,как у тебя, в первой версии).

Denis GladkikhiВ них нет такого "феерического бреда"(буду придерживаться твоей терминологии), который ведет к большим накладным расходам и тормозам, как пообъектная валидация, когда она применима ко всему типу(длина строки,not null,etc)
Видимо я действительно глуп, расскажите, пожалуйста, поподробнее где здесь накладные расходы. Можете по пальцам показать?


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

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