Каковы плюсы и минусы View-first и ViewModel-first в шаблоне MVVM [закрыто]

Я делаю презентацию об использовании MVVM в реальных приложениях, и я включаю раздел орелигиозные войны проектные решения, связанные с использованием MVVM в качестве шаблона в вашем приложении. В приложении MVVM есть два основных способа (о которых я знаю) для создания новой пары View / ViewModel:

Вид-первых в котором вы создаете представление, и оно создает свой собственный ViewModel и устанавливает его в свой DataContext.ViewModel-первых в котором вы создаете новые модели представлений и создаете новые представления в ответ на изменения свойств ViewModel, обычно с помощью ItemsControls и / или DataTemplates.

По вашему опыту, каковы плюсы и минусы каждого метода? Что они дают и с какими проблемами вы сталкиваетесь?

Сводка результатовПосмотреть сначала - ПлюсыЛегко отслеживать, какая ViewModel используется ViewПосмотреть сначала - минусыНе позволяет легко использовать один вид с несколькими моделями представленияТребуются дополнительные события для обработки связи между Views и ViewModelsViewModel Первый - ПлюсыПозволяет более полно тестировать логику для открытия новых видов и моделей представленияИмеет тенденцию быть сухим, поскольку приложения становятся большеView и ViewModel являются более независимыми и могут работать легче отдельноViewModel Первый - минусыСложнее настроить в Silverlight без DataTemplateSelector и типизированных DataTemplates.

Ответы на вопрос(6)

я считаю, что ViewModel-First - это способ, которым WPF былпредназначена использоваться.

Я поясню это утверждение: Data Templating позволяет вам никогда не создавать экземпляры представлений из вашей ViewModel. Если все сделано правильно, ваши Views и ViewModels могут быть сохранены в отдельных проектах, которые НЕ ссылаются друг на друга. Кроме того, проект ViewModel даже не должен ссылаться на какие-либо сборки PresentationFramework, что делает ваши ViewModels пригодными для использования любым мыслимым пользователем.

 Bryan Anderson18 окт. 2012 г., 18:07
Нет проблем, это все еще хороший ответ, поскольку он объясняет одно из преимуществ VM-first.
 Reversed Engineer09 апр. 2019 г., 11:38
Вопрос такой же в 2019 году, как и в 2009 году, и ответы до сих пор актуальны :)
 Andre Luus18 окт. 2012 г., 10:57
Извиняюсь за то, что разбудил этот почти древний вопрос.

в сотрудничестве с моим клиентом с помощью фиктивной модели представления с тестовыми данными. Когда мы удовлетворены, я продолжаю извлекать интерфейс из «пустышки» и реализую настоящую ViewModel. Я нашел этот подход наиболее привлекательным по следующим причинам:

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

Я работаю в WPF, но я думаю, что в SL не будет ничего особенного. Кроме того, я никогда не трачу время на тестирование представлений, которое может быть связано с моим выбором подхода.

 Bryan Anderson21 сент. 2010 г., 20:51
Я ищу, какое приложение вы запускаете, когда программа выполняется, а не то, которое вы сначала пишете / проектируете. Извините за путаницу.

Посредством создания экземпляра V виртуальной машины (как я это делаю) представление является независимым и может использоваться независимо от виртуальной машины (например, в конструкторе)

Лично я склоняюсь к MVVMC (модель, View, ViewModel, Controller), где у меня есть управляющий класс, который создает экземпляры ViewModels и Views и «присоединяет их». Затем C также обрабатывает получение данных (и их кэширование и т. Д.) И любой обмен данными через VM и V (например, если создается экземпляр V, направляет команду на свою VM для выполнения какого-либо действия, VM, вероятно, попросит C выполнить действие от своего имени, C может затем вызывать соответствующие события, которые могут обрабатывать другие виртуальные машины

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

но когда пришел на аутсорсинг, и использование blend стало самой важной вещью, мой босс сказал, что View-first лучше, чем Viewmodel-first - я с ним не согласен (но соотношение один к многим не лучшее соотношение голосов ;-)), потому что теперь у нас есть несколько странных связей с событиями в коде позади. Теперь я нахожусь в точке невозврата, и я застрял в некоторых пользовательских элементах управления - из-за изменений.

 Bryan Anderson28 сент. 2010 г., 17:42
Обычный способ сделать View-First состоит в том, чтобы View реализовывал интерфейс (например, IScreen) и передавал себя ViewModel в конструкторе. Это очень помогает с дополнительными событиями, так как они обычно заканчиваются небольшим набором (например, CloseScreen). Я считаю, что Caliburn Framework (caliburn.codeplex.com) имеет довольно хорошую реализацию и набор документации, если вам интересен пример.

огим причинам:

Vms - это ваше приложение, содержащее большую часть логики, кроме связующего кода в форме поведения или триггеров.Если вы создаете представления, то вы несете ответственность за его жизнь и код очистки. Вы должны иметь дело с многопоточностью и другими проблемами, которые трудно проверить. С другой стороны, вы создаете vms и оставляете логику создания представлений в WPF через шаблон данных ... вам не нужно беспокоиться о потоке. И будет лучше разделение проблем.С vm первый подход нулевого кода позади.С изоляцией на уровне проекта для view и vms вы можете ограничить разработчиков, используя определенные вещи вида, например диспетчер в модели представления, оставляя более чистую и тестируемую базу кода. Т.е. посмотреть проект sprojec to vm. И проект vm не должен ссылаться на какую-либо презентацию lib.Если есть четкая граница между видом и vm. Оба могут развиваться и будут менее хрупкими.

что чувствую, что она лучше всего следует правилу DRY. Когда вы начинаете создавать более масштабные приложения, я нахожу, что это также облегчает тестирование, таким образом перевешивая начальную долю головной боли, с которой вам нужно иметь дело при настройке приложения.

Ваш ответ на вопрос