Ответ 1
почему пустая кодировка рассматривается как хорошо спроектированная MVVM
Наличие файла кода, состоящего исключительно из вызова InitializeComponent() в его конструкторе, означает, что вы достигли чистоты - у вас абсолютно нулевая логика в вашем коде. Вы не загрязнили свой взгляд любым кодом, который по праву принадлежит модели viewmodel или модели. Это означает пару вещей:
- viewmodel (и модель) легче тестировать изолированно
- вы достигли хорошего уровня свободной связи, которая имеет отличные преимущества от перспективы обслуживания и расширяемости.
Преимущества действительно становятся заметными, когда вам нужно изменить свой пользовательский интерфейс, то есть переключиться с использования ListView на DataGrid или изменить стандартное управление Microsoft на использование некоторых других поставщиков.
Как уже упоминалось, иногда невозможно избежать небольшого кода в файле кода. Вы должны убедиться, что код, который у вас есть, связан исключительно с пользовательским интерфейсом. В качестве примера, если у вас есть ComboA и ComboB, а ComboB установлен в ответ на выбор в ComboA, то установка SelectedIndex из ComboB из представления прекрасна, но установка элементов или SelectedItem ComboB не является - эти свойства оба связаны с данными и должны быть указаны посредством привязки к viewmodel. Свойство SelectedIndex непосредственно визуально связано и несколько не зависит от фактических данных (и оно не имеет отношения к viewmodel).
Если вы просматриваете viewmodel из кода в представлении, вы должны попробовать и сделать это через интерфейс. Это означает, что ваш viewmodel вводится или передается в виде интерфейса. (Обратите внимание, что подсистема привязки не знает или не заботится об интерфейсе, она будет продолжать связываться по-своему. То, что это достигается, - это лучший код с менее жесткой связью). То, как я его кодирую, viewmodel не имеет представления о том, что существует представление, и представление только знает о viewmodel как интерфейсе.
Одна вещь, которую следует помнить, это то, что MVVM - это шаблон, а шаблон - это просто рецепт или рецепт для достижения определенного результата в определенная ситуация. Его нельзя рассматривать как религию, где неверующие или неконвертеры собираются пойти в какой-нибудь чистилище (хотя соблюдение паттерна хорошо, если вы хотите избежать чистилища обслуживание ада и запах кода).
Если вам нужен отличный пример того, как этот конкретный шаблон помогает, попробуйте написать несколько достаточно сложных экранов в ASP.Net, а затем напишите их в WPF или Silverlight и обратите внимание на разницу.
Edit:
Позвольте мне ответить на некоторые ваши вопросы, надеюсь, это поможет...
роль viewmodel (model of view), на мой взгляд, имеет логику пользовательского интерфейса и состояние представления
В моделях просмотра никогда не должно быть логики пользовательского интерфейса или "состояния представления". В целях этого объяснения я бы определял состояние представления как положение прокрутки, выбранный индекс строки, выбранный индекс, размер окна и т.д. Ни один из них не принадлежит в модели view; такие вещи, как SelectedIndex, специфичны для способа отображения данных в пользовательском интерфейсе (если вы изменили порядок сортировки DataGrid, то SelectedIndex может измениться, хотя SelectedItem все тот же). В этом конкретном случае SelectedItem может быть привязан к viewmodel, но SelectedIndex не должен.
Если вам нужно отслеживать информацию о типе сеанса пользовательского интерфейса, тогда вы должны придумать что-то общее (например, я сохранил состояние представления раньше, сохранив важные материалы в списке KeyValuePair), который затем "сохраняется" с вызовом viewmodel (через интерфейс, о котором я упоминал ранее). Представление не имеет представления о том, как данные сохраняются, и модель представления не имеет представления о том, что данные поступают из представления (он просто обнаружил вызов через свой интерфейс).
а роль представления отображает некоторое содержимое и синхронизирует viewmodel (имеющий код привязки данных)
Да, ответственность за просмотр - это просто визуальное отображение данных, представленных моделью. Модель viewmodel получает данные из модели (модель отвечает за вызовы базы данных или вызовы webservice WCF, это обычно делается с помощью "службы", но это еще одно обсуждение). Теперь модель просмотра может формировать или манипулировать данными, т.е. Она может получать список всех клиентов, но только выставлять отфильтрованную версию этого списка (возможно, текущих клиентов) в общедоступном свойстве, к которому может привязываться представление.
Если данные должны быть обработаны во что-то визуальном (общий пример - это значение перечислимого числа, которое переводится в цвет), тогда модель просмотра все еще имеет только значения (-ы) перечисления, и представление все еще привязывается к этому значению, но представление также использует конвертер для перевода чистых данных в визуальное представление. Используя конвертер, модель просмотра все же избегала делать что-то связанное с UI, и представление избегало какой-либо реальной логики.