Посмотри в Silverlight/Showcase .
Загрузка ноль% в споконом состоянии. Твой пример - кривые руки, которые ни о чем не говорят

i seeМСУ Выступление на ADD2010: Silverlight/WPF: возврат от паттерна MVVM к MVP
О чём я и говорил тут: 9903653

пропущено...
Судя по нику участника, отстаивающего эту позицию в топике, и имени автора выступления, "массовых выступлений" против MVVM пока что не видно.
И тут и там - один и тот же :)

Весомых аргументов тоже не видно
авторВ большинстве случаев реализации MVVM паттерна модель представления имеет очень много причин для изменений. Если нам нужно на представлении поменять немного логику, использовать другое связывание данных, то, скорее всего, нужно будет менять и логику в модели представления. Если поменялась модель, то нужно менять за ней и модель представления. Одни из самых важных принципов разработки – это «разделение ответственности» (Seperation of Concerns) и «принцип единственной ответственности» (Single Responsibility Principle). В случае модели представления эти принципы нарушены.
Данную проблему можно решить, вернувшись обратно к паттерну MVP с небольшими доработками. Основой этих доработок будет являться облегченная версия модели представления, описанной Мартином Фаулером [3]. В данном случае эта модель представления возьмет на себя только задачу связывания данных, и в некоторых случаях их валидацию. В результате у нас будет презентатор, который будет выполнять действия по запросу пользователя, модель представления, которая будет связывать данные с представлением, само представление, а так же модель. Каждый компонент фокусируется на более специфичных задачах вместо охвата нескольких, что дает нам, например, преимущества в написании тестов. Данный подход не только делает код более читабельным и классы более сфокусированными, так же у нас появляется возможность использовать облегченную версию модели представления сразу на нескольких представлениях


MVVM - MVP без View.
"Если нам нужно на представлении поменять немного логику" это придется делать и в MVP.
"Если поменялась модель, то нужно менять за ней и модель представления", а это делать совершенно необязательно, если Model отдельное свойство MVVM.
Помимо этого, MVP есть еще одно существенное усложнение, которое соврешенно не отвечает принципу единичной ответственности - в нем должна быть заложенна логика управления предтавлением и связыванием с данными.

МСУDenis GladkikhДаю просто совет. ;) И то, что попалось на глаза не отображает всю действительность. Погуглите и посмотрите сколько народу задумывается о сравнении MVP и MVVM и увидите ;)
+1, Дениска. Верно вещаете ))

P.S. За TDD тоже согласен. Была даже ссылка, постил как-то, что специалисты пишут, что 100% покрыть код автотестами невозможно впринципе. Всех комбинаций и поведений не учтешь. Выводы - мы пишем тест, а не программу (если серьезный проект), тратим много времени на имзменение теста под новые задачи оптимизации и кастома. И так далее. В современных условиях заказчик не готов платить на время - ему нужно быстро и чтоб работало так, как нужно ему. Ну и так далее...

-100, Данилка вещает, как всегда о вещах не имея ни малейшего представления о них.
Основные аргументы сторонников TDD - заказчик не готов платить за полное обследование и проектирование по науке или это не имеет смысла, тк пока будет рисовать красивые диаграммы бизнес-требования успеют десять раз поменяться.
Посему действуем по принципу - "быстро шьем и еще быстрее распарываем", а для этого нужны unit test'ы, иначе далеко не уедем с ручным тестированием

МСУi-100, Данилка вещает, как всегда о вещах не имея ни малейшего представления о них.
Данилка вещает о вещах, имея шикарное представление о них.
Слыхал о таком парне под именем Joel Spolsky? Давай посмотрим на "Разоблачение юнит-тестов и TDD в частности": 9690683

МСУРазоблачение юнит-тестов и TDD в частности.
Юнит тесты и TDD
Основной упор сделан на то, что юнит-тесты - бесполезная штука. Модная, но бесполезная.
Лично я согласен с автором.

пропущено...


... читаем дальше :)

iОсновные аргументы сторонников TDD - заказчик не готов платить за полное обследование и проектирование по науке или это не имеет смысла, тк пока будет рисовать красивые диаграммы бизнес-требования успеют десять раз поменяться.
Поверь мне, TDD нисколько не ускоряет работу без полного обследование, которое является, вообще-то, аналитической работой. Ты вообще не в тему приплёт сюда обследование, клоун

iПосему действуем по принципу - "быстро шьем и еще быстрее распарываем", а для этого нужны unit test'ы, иначе далеко не уедем с ручным тестированием
Жесть. Ты хоть раз когда-нибудь хоть один тест написал?
С тестами априори быстрее не сошьешь ))

Муся, не переживай за меня. Их другие пишут.