SeVa
Алексей КИзопропил давайте вернёмся к обсуждению MVVM
Имеет ли смысл во всех случаях выносить из ViewModel в другой класс львиную долю логики и оставлять только "прослойку" для взаимодействия Model <=> View через датабиндинг? Даже если выносимый код используется только в контексте данного ViewModel и в дальнейшем изменения ситуации не планируется. Что об этом говорят идейные вдохновители MVVM?
Хороший вопрос.
Теоретики сами озадачены этим вопросом и ничего внятного не говорят.
Еще одно обсуждение .
Сам по себе MVVM многих проблем не решает.Я для себя остановился пока на следующем варианте.
- работа с БД через Repository.С помощью Reactive Framework(Linq for Events будет входить в состав Net 4.0,для SL уже есть в Toolkit), удалось полностью избавится от необходимости написания асинхронных callback'ов,что дало идентичный код для серверной и клиентской частей.
- Унификация взаимодействия с БД позволила создавать базовые ViewModel, в них оставил только SCRUD (валидация в Моdel).
- Бизнес логика,создание View&ViewModel,композицию форм вынес в контроллеры.Их вызов удобней делать не с помощью ICommand, которые подразумевают явное создание команд, а через Routing по принципу ASP.Net MVC. Переходы задаются в текстовом виде(модуль/контроллер/действие/параметры) , их легко создавать и осуществлять binding.Кроме того, при таком подходе несложно сделать загрузку модулей по требованию.
Пока такой вариант полностью устраивает, основная работа сводится только к реализации бизнес-логики.Проблемы сейчас другие - приходится ломать голову над тем,как сделать более удобный интерфейс.Возможностей много,шаблоны не отработаны и это весьма тормозит процесс.
У меня 3 вопроса к SeVa:
что значит S в новоявленной аббревиатуре "SCRUD"? (вроде бы, всегда хватало CRUD aka C[reate]R[etrieve aka select]U[pdate]D[elete]);

как рассуждения Ward-a Bell-a о целесообразности введения "Screen Factory" ("View Factory") в WPF\SL приложении соотносятся с ответом на вопрос Алексея К о целесообразности вынесения к.-л. логики из VM вообще? (вроде бы, с логикой ли, без логики ли, а создавать VM в составе "триады" все равно надо и эти 2 вопроса - абсолютно ортогональны);

как в описанной вами структуре (архитектуре?) приложения обрабатываются "переходы в виде: модуль/контроллер/действие/параметры"? Подразумевает ли этот способ обработки наличие некоего "ViewEngine" ("по принципу ASP.Net MVC"), который строит V "на лету" (в виде XAML или еще чего-нить "декларативного") и отсылает клиенту только на "рендеринг" и отображение, фактически превращая UI-часть WPF\SL приложения в аналог браузера, но не для HTTP/HTML, а для XAML или любого другого "проприетарного" формата?

З.Ы. кстати, по принципу описанному в 3-ем вопросе еще 20 (25?) лет назад строился клиент для SAP\R3 (наверное, и сейчас строится, я уже выпал из контекста).