Кто-то из Silverlight опубликовал, что MVVM в настоящее время не имеет стандартизации, так что каждый имеет свой собственный вкус.
Вот почему я и несколько парней из WPF Disciples активно обсуждают, какие элементы MVVM все согласны. Я полностью понимаю, что мы реализовали шаблон по-разному, и мы смешали несколько шаблонов или создали наш собственный шаблон, основанный на потребности нашего проекта, или облегчили жизнь разработчиков. Но забудьте об этих трудностях или особой необходимости вашего проекта, Давайте обсудим стандартные правила шаблона MVVM, которые все согласились. Я разместил некоторые из моих мыслей здесь.
Почему MVVM?
- Testabiltiy (ViewModel проще unit test, чем код-код или управляемый событиями код)
- Четкое разделение между дизайнером UX и разработчиком
- Увеличивает "Смешиваемость" вашего представления.
- Модель не нуждается в изменении для поддержки изменений в представлении
- ViewModel редко необходимо изменить для поддержки изменений в представлении
- Нет дублированного кода для обновления представлений
Do and Dont in View
- не должен содержать никакой логики, которую вы хотите протестировать: поскольку Гленн сказал, что MVVM не является упражнением для подсчета кода, мы можем написать код в коде. Но вы никогда не должны писать какую-либо логику, которую хотите протестировать. Например: если пользователь выбирает страну, то вы хотите отобразить список состояний или города в своем представлении. Это бизнес-требование, поэтому вы должны иметь unit test для проверки этой логики. Таким образом, вы не должны писать его в коде.
- может быть элементом управления или шаблоном данных
- Сохраняйте представление как можно проще.: Мы все еще можем с осторожностью использовать Data Trigger или Value Converter или Visual State или Blend Behavor в XAML.
- использовать прикрепленное свойство, если что-то не является связываемым:
Do и Dont в ViewModel
- Коннектор между представлением и моделью
- Keep View State, Value Conversion (вы можете создать структуру данных, которую вы хотите отобразить в ViewModel, вместо использования ValueConverter. Например: вам нужно показать Имя вместо имени и фамилии. Имя и фамилия, но вы можете создать свойство Name в ViewModel.)
- Нет сильной или слабой (через интерфейс) ссылки View
- Сделайте VM максимально возможным (например, нет вызова класса Singleton)
- В VM нет элемента управления, связанного с ним (потому что, если вы меняете представление, вам также придется изменить VM).
Model
- может быть модель данных, DTO, POCO, автоматически сгенерированный прокси класса домена и модели пользовательского интерфейса, основанный на том, как вы хотите иметь разделение между доменной службой и уровнем презентации
- Нет ссылки на ViewModel
Есть ли у вас какие-либо предложения или комментарии?
У нас есть одно несогласие в нашей группе. Некоторые сказали, что хорошо иметь интерфейс View в ViewModel. Но некоторые сказали, что если View Model имеет интерфейс View, то это будет шаблон MVP.
Один из наших экспертов MVVM говорит о MVVM Vs MVP
View = > ViewModel
- MVVM представление напрямую связано с ViewModel и ведет переговоры с VM через привязку данных
- В MVP представление привязано к модели, свисающей с SupervisingController или вообще не связанной (пассивное представление).
ViewModel = > Просмотр
MVVM
- INPC/привязка свойств
- События
- Сообщения (Event Aggregator/Messenger/RX framework)
- Через посредника, такого как служба
- Через интерфейс
- Через делегаты (View передает делегаты на виртуальную машину, которую он может использовать для ее вызова). Например, VM может выставить метод SetActions, который передает вызов, передающий его делегаты.
MVP
В случае MVP стандарт - это презентатор, который возвращается к представлению через интерфейс, привязку данных или через свойства в случае пассивного представления. С пассивным представлением свойства не используют привязку данных, вместо этого используются свойства getres и seters свойств представления, чтобы напрямую установить контрольное значение.
Что вы думаете об этой идее?
Считаете ли вы, что для ViewModel это нормально, есть интерфейс View?
Если вы хотите добавить еще, вы можете добавить...:)
Вся идея этой публикации - получить то же самое представление о шаблоне MVVM в Сообществе.
