Каковы основные различия между MVVM и MVC в проекте WPF?

Question

Я хотел бы получить информацию о том, какие основные отличия между проектом MVVM и проектом MVC. Я знаю основные принципы MVVM и MVC, но я хотел бы узнать более технически об их различии в проекте WPF.

Answer 1

Другие ответы здесь говорят о некоторых преимуществах MVVM, но я чувствую, что они не могут ответить на вопрос. Я считаю, что вы задаете философский вопрос о различии MVC и MVVM.

По моему опыту, контроллер MVC отвечает за запуск изменений состояния в представлении и модели.Например, ваше мнение может иметь такую ​​функцию:

public void SetupListBox(List<string> items) {...} 

Или что-то еще более монолитным, где много битов информации предоставляются сразу:

public void SetupForm(string name, List<string> listItems, string selectedItem) {...} 

Контроллер будет явно вызывать этот тип метода для запуска изменения состояния, а вид (в этом случае) изменит его состояние в рамках метода.

С MVVM, то ViewModel публично выставляет состояние зрения, как правило, на детальном уровне:

public string Name { get {...} set {...} } 
public List<string> ListItems { get {...} set {...} } 
public string SelectedItem { get {...} set {...} } 

ViewModel также несет ответственность за уведомление мнение, что соответствующее изменение состояния произошло. Для этого WPF использует для этого метод INotifyPropertyChanged.

Один из способов думать о том, что ViewModel абстрактно представляет состояние, которое ДОЛЖНО присутствовать в представлении. Независимо от того, действительно ли это состояние отражается в представлении, зависит от того, насколько хорошо вы реализовали свою архитектуру.

Обратите внимание, что MVC и MVVM не являются конкурирующими шаблонами. С MVVM вам все еще нужна логика для изменения состояния. Главное различие заключается в том, где живет это государство. Часто проще всего переключить эту логику изменения состояния в ViewModel. Для больших приложений может потребоваться архитектура MVVMC.

Answer 2

Наиболее значительная разница, которую я вижу, - это акцент на возможности «выключения частей» с использованием MVVM. Идея состоит в том, что модель не знает о ModelView, и аналогично ModelView не знает о представлении. Поэтому, если вы полностью перепроектируете View, ModelView не будет затронут.

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

С MVVM модель должна быть в состоянии просто делать свою работу с данными, не обращая внимания на то, не заботится ли кто-либо за ее пределами о том, что он делает. ModelView должен иметь возможность использовать все классные вещи, которые делает Модель, и делать расходные материалы доступными для внешних ресурсов, но в противном случае следует забывать о том, как конечный пользователь будет выполнять потребление. Наконец, View знает о ModelView и может получить от него все, что ему нужно, чтобы настроить опыт для своего пользователя.

Две большие точки продажи - это то, что вы можете легко и просто отключить представление (почти). ModelView ничего не знает о представлении, поэтому он работает независимо. То, как View подключается к ModelView, полностью зависит от вида. Другим моментом является то, что вы можете модульно тестировать Model и ModelView в относительной изоляции. Вам не нужно инициализировать компонент View для его запуска.

Хотя долго и несколько густая, это хорошо читать: https://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Answer 3

Оба из них являются архитектурные узоры, чем старше MVC, то приходит MVP (Model View Presenter) и от MVP наследует MVVM.

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

В других типах приложений, таких как Web-формы Asp.Net или Windows Forms, единственный способ, которым мы достигаем этого, - написать «код позади», где мы контролируем взаимодействие пользователей и помещаем логику представления, это обычно используется MVP и MVC, таким образом, у вас больше кода, который зависит от пользовательского интерфейса, и простое изменение пользовательского интерфейса может привести к поломке большего количества кода.