Стандартизация MVVM

Кто-то в Silverlight отправил это, MVVM в настоящее время испытывает недостаток в стандартизации так, чтобы у всех была собственная разновидность..

Вот почему меня и несколько парней от Учеников WPF активно обсуждают, какие элементы MVVM, который все согласовали. Я полностью понимаю, что мы реализовали шаблон по-разному, и мы смешали эти несколько шаблонов, или создайте наш собственный шаблон на основе потребности нашего проекта или сделать жизнь разработчиков легче.. Но забудьте о тех трудностях или специальной потребности Вашего проекта. Давайте обсудим о стандартных правилах шаблона MVVM, что все согласились. Я отправил некоторые свои мысли здесь также.

Почему MVVM?

• Testabiltiy (ViewModel легче к модульному тесту, чем код - позади или управляемый событиями код),
• Четкое разделение между разработчиком UX и разработчиком
• Увеличивает “Смешиваемость” Вашего представления
• Модель никогда не должна изменяться для поддержки изменений в представлении
• ViewModel редко должен изменяться для поддержки изменений в представлении
• Никакой дублированный код для обновления представлений

Сделайте и не делайте в поле зрения

• не должен содержать логику, которую Вы хотите протестировать: Поскольку Glenn сказал, что MVVM не является кодом, считая осуществление, мы можем написать код в коде - позади. Но Вы никогда не должны писать логику, которую Вы хотите протестировать. Например: Если пользователь выбирает страну затем, Вы хотите отобразить список состояний или города в Вашем представлении. Это - бизнес-требование, таким образом, у Вас должен быть модульный тест для тестирования этой логики. Так, Вы не должны писать это в коде - позади.
• может быть Шаблон Данных или управление
• Сохраните представление максимально простым.: Мы можем все еще использовать Преобразователь Триггера или Значения Данных или Визуальное состояние или Смешение Behivor в XAML с осторожностью.
• используйте присоединенное свойство, если что-то не связываемо:

Сделайте и не делайте в ViewModel

• Коннектор между представлением и моделью
• Сохраните Состояние отображения, Преобразование Значения (Можно создать структуру данных, которую Вы хотите отобразить в ViewModel вместо того, чтобы использовать ValueConverter. Например: необходимо показать Имя вместо Имени и Фамилии. Ваша Модель может иметь Имя и Фамилию, но можно создать свойство Name в ViewModel.)
• Нет сильный или слабый (через Интерфейс) ссылка Представления
• Сделайте VM максимально тестируемым (например, никакой вызов к Singleton-классу)
• Никакой связанный с управлением Материал в VM (Поскольку при изменении представления затем, необходимо будет изменить VM также.)

Модель

• может быть Модель данных, DTO, ПОСТЕПЕННО, автоматически сгенерировал прокси доменного класса и UI, Основанного на модели о том, как Вы хотите иметь разделение между Доменным Сервисом и Уровнем представления
• Никакая ссылка на ViewModel

У Вас есть какое-либо предложение или комментарий для этого?

У нас есть одно разногласие в нашей группе. Некоторые сказали, что это должно хорошо иметь интерфейс Представления в ViewModel. Но некоторые сказали, что, если Модель Представления имеет интерфейс Представления затем, это будет шаблон MVP.

Один из наших экспертов MVVM говорит о MVVM По сравнению с MVP

Представление => ViewModel

• MVVM представление непосредственно связывается с ViewModel и говорит с VM посредством привязки данных
• В MVP представление связывается с моделью, зависающей от SupervisingController, или не связывается вообще (пассивное представление).

ViewModel => Представление

MVVM

1. INPC / привязка Свойства
2. События
3. Сообщения (Событие платформа Aggregator/Messenger/RX)
4. Через посредника такой как услуга
5. Через интерфейс
6. Через делегатов (Представление передает делегатов в VM, который оно может использовать для призывания обратно его. Например, VM мог бы выставить метод SetActions, который вызовы Представления, передающие его, делегирует.

MVP

В случае MVP стандарт является Предъявителем, возражает к представлению или через интерфейс, привязку данных, или через свойства в случае представления Passive. С Пассивным Представлением свойства не используют привязку данных, вместо этого методы считывания свойства представления и методы set используются для прямого устанавливания значения управления.

Что Вы думаете о той идее?

Вы думаете, что это хорошо для ViewModel, имеют интерфейс Представления?

Если Вам нравится добавлять больше затем добро пожаловать для добавления... :)

Вся эта мысль об этом сообщении состоит в том, чтобы получить то же понимание шаблона MVVM в Сообществе.