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

Question

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

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

Почему MVVM?

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

Делай и не види

• не должно содержать никакой логики, которую вы хотите протестировать: поскольку Гленн сказал, что MVVM - это не упражнение по подсчету кода, мы можем написать код в коде позади. Но вы никогда не должны писать какую-либо логику, которую хотите проверить. Например: если пользователь выбирает страну, то вы хотите отобразить список штатов или города в вашем представлении. Это бизнес-требование, поэтому вам нужно пройти модульный тест для проверки этой логики. Таким образом, вы не должны писать это в коде позади.
• может быть элементом управления или шаблоном данных
• Сделайте вид максимально простым. : Мы все еще можем с осторожностью использовать Data Trigger или Value Converter, Visual State или Blend Behivor в XAML.
• использовать прикрепленное свойство, если что-то не связывается:

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

• Разъем между View и Model
• Сохранить состояние просмотра, преобразование значений (Вы можете создать структуру данных, которую хотите отобразить в ViewModel, вместо использования ValueConverter. Например: вам нужно показывать имя вместо имени и фамилии. Ваша модель может иметь имя «Первый»). Имя и Фамилия, но Вы можете создать свойство Name в ViewModel.)
• Нет сильной или слабой (через интерфейс) ссылки на View
• Сделать виртуальную машину как можно более тестируемой (например, не вызывать класс Singleton)
• Нет вещей, связанных с управлением в ВМ (потому что, если вы меняете представление, вам также придется менять ВМ.)

Модель

• может быть Модель данных, DTO, POCO, автоматически сгенерированный прокси класса домена и Модель пользовательского интерфейса, основанная на том, как вы хотите разделить между Доменной службой и Уровень представления
• Нет ссылки на ViewModel

У вас есть предложения или комментарии по этому поводу?

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

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

View => ViewModel

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

ViewModel => Вид

МВВМ

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

MVP

В случае MVP стандартом является то, что докладчик возвращает данные представлению либо через интерфейс, привязку данных, либо через свойства в случае пассивного представления. В пассивном представлении свойства не используют привязку данных, вместо этого методы получения и установки свойств представления используются для непосредственной установки значения элемента управления.

Что вы думаете об этой идее?

Как вы думаете, нормально ли для ViewModel иметь интерфейс View?

Если вы хотите добавить больше, вы можете добавить ...:)

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

Answer 1

Мне нравится то, что вы написали. Одна из вещей, которая меня действительно беспокоит, это то, что многим людям кажется, что их виртуальная машина очень тесно связана с их View - если вы делаете это, то с тем же успехом вы можете просто делать старый XAML + - все, что попадает код позади вещь.

Шаблон, который я использую, является небольшим вариантом на MVVM (но в основном он такой же). Лично я хотел бы, чтобы моя ViewModel была передана View как интерфейс - он поддерживает разделение очень чистым. Это дает много преимуществ при создании прототипов, визуальные элементы могут включаться или выключаться из представления, практически не влияя на ViewModel.

Answer 2

Я думаю, что связь между View ViewModel через привязку данных делает MVVM своим собственным шаблоном, а не другим разделением интересов. Это не так много, будь то ХОРОШО или ПЛОХО для vm, чтобы узнать о представлении через интерфейс, но в контексте передачи используемого шаблона это не MVVM.

Некоторые трудности в получении и поддержании стандартов к сожалению связаны с недостатками и сложностью WPF и Silverlight. Однако, когда существует несколько действующих стандартов, я надеваю шляпу Мартина Фаулера и добавляю раздел «когда его использовать».

Ваши стандарты охватывают такие сквозные проблемы, как локализация?

FWIW Мне нравится содержание того, что вы написали, и я рад, что вы разместили его здесь ...

Приветствия
Berryl