MVP против MVVM - почему

Я использовал MVP, когда работал с winform. но я перешел в MVVM, когда начал играть с WPF или Silverlight.

Единственное, что я заметил, это то, что нам не нужно синхронизировать данные между View и ViewModel в шаблоне MVVM из-за мощной привязки.

Мой вопрос ~

1) Связывание (что помогает нам не синхронизировать View и ViewModel вручную) является единственным преимуществом использования MVVM.

2) Есть ли другие преимущества MVVM над MVP? в чем отличия?

3) Ниже приведен код MVVP или MVVM или оба?

interface IView{

  void ShowMessage(string message);

}

class View : IView {
    public void ShowMessage(string message){
              MessageBox.Show(this, message);
    }
}

class ViewModel{

private IView view;

public ViewModel(IVew view){

  this.view = view;

}

........

view.ShowMessage("This is a msg");

}

Спасибо.

Ответ 1

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

-1 - Я не уверен, что вы просите, но я думаю, что вы спрашиваете: является ли единственное преимущество MVVM? Ответ - нет. Разделение проблем, привязка и эффективное тестирование являются основными преимуществами для MVVM. Есть много незначительных преимуществ, но я не буду вдаваться в них. Связывание абсолютно замечательно, потому что вся синхронизация автоматизирована, что означает меньшую работу для вас. Кроме того, разделение проблем означает, что модель представления не зависит от типа представления, поэтому вы можете иметь несколько представлений с использованием одной и той же модели представления. Например, скажем, что вы создаете модель представления с именем ErrorDataViewModel. Цель этого класса - сохранить список классов ErrorType, которые будут отображаться пользователю. ErrorType в основном показывает информацию об ошибках. ErrorDataViewModel также имеет свойство boolean, называемое AllErrorsFixed, которое позволяет пользователю узнать, были ли исправлены все ошибки в списке. AllErrorsFixed - это простое свойство, которое использует linq для запроса списка свойств ErrorTypes.Fixed. Если все фиксированы, AllErrorsFixed вернет true.

В приложении 1 ваш клиент хочет, чтобы ошибки отображались в простой форме сетки. Все, что вы делаете, это привязать сетку к списку ошибок в этом представлении. В Application2 ваш клиент хочет, чтобы ошибки отображались в большей части навигационного формата, где они могли просматривать каждую форму ошибки по форме. Все, что вы делаете, это привязать элемент управления формы к каждой ошибке в списке и настроить навигацию для перехода от одной записи к другой. Но подождите, если мы хотим, чтобы App1 использовал как сетку, так и формульную навигацию, мы можем это сделать. Еще лучше, теперь вы хотите внедрить веб-интерфейс с помощью Silverlight для замены Application1/Application2 или другого продукта, вам не нужно менять модель представления. Работа выполнена.

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

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

-2 - Есть ли какие-либо преимущества для MVVM или MVP. Да. Один плакат был неправильным, говоря, что в одном представлении может быть несколько виртуальных машин в MVVM. Фактически, одна виртуальная машина может иметь несколько видов, потому что она не привязана к виду. Или иначе, несколько видов могут использовать одну виртуальную машину. Итак, в вашем примере, где вы вызываете view.ShowMessage(), это не произойдет в MVVM, потому что вы не можете гарантировать, что представление (WPF или Silverlight или тестовый класс) имеет метод ShowMessage. Вместо этого вы запускаете событие. На самом деле, Prism является удивительным с этим, потому что он имеет агрегаторы событий, поэтому, когда вы запускаете событие, агрегатор событий обрабатывает отправку события в представление, назначенное этому событию. Поэтому каждый вид приложения может обрабатывать событие, как он считает нужным. С MVP вам нужно создать презентатор для каждого представления. Это занимает много времени.

-3 - Ваш примерный код - MVP.

Ответ 2

Пример MVP, четко определенный этой строкой:

view.showMessage("This is a msg");

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

Это имя Microsoft для менее известного шаблона PM (Presentation Model) - вы можете прочитать его описание.

Ответ 3

Я уже ответил на один подобный вопрос, но вам это может быть полезно и вам:

Основные функции обоих из них для использования в среде Android.

Шаблон MVP:

  • Состоит из слоев Model, View и Presenter;
  • Просмотр делегатов ввода пользователем в Presenter; оба слоя должны иметь отношение 1 к 1;

  • Просмотр и модель arent плотно соединены для четкого разделения проблемы;

  • Просмотр напрямую подключается к модели посредством привязки данных;

  • Простое тестирование модулей, поскольку интерфейс для уровня Presenter один может макет быстро,

Рисунок MVVM:

Включает три ключевые части:

  • Модель (бизнес-правило, доступ к данным, классы),

  • Просмотр (пользовательский интерфейс),

  • ViewModel (как агент между представлением и моделью);
  • Отличное решение для обработки задач, связанных с представлением Windows Foundation (WPF) и платформа приложений Silverlight;
  • Обеспечивает более четкое разделение логики пользовательского интерфейса и приложения;
  • Тестирование модулей еще проще, так как нет зависимости от представления

Сравнение функций

Давайте рассмотрим основы MVP и MVVM для сравнения. Мы также должны подчеркнуть, что мы выступаем за один или образец.

Метрики кода: MVP может создавать больше классов и Java-код. В MVVM больше классов Java, но меньше кода для каждого класса.

Поддержание работоспособности: MVP легко изучить, изменить, добавить функции. Добавление новых функций с помощью MVVM может потребовать некоторого опыта работы с библиотекой.

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

Ввод данных: начинается с представления в MVP, а не с презентатором. Вход в MVVM начинается с представления, а не с ViewModel.

Сопоставление и ссылки: сопоставление "один к одному" между представлением и презентатором в MVP, без ссылки между ними. Отображение "один ко многим" между View и ViewModel в MVVM, без ссылки.

Заключительные слова

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

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

Когда использовать MVP и когда использовать MVVM, вы можете спросить? Рекомендации скрываются скорее в привязке данных. В случаях, когда привязка к datacontext невозможна, большинство разработчиков предпочитают MVP (Windows Forms - отличный пример). MVVM предпочтителен в случаях, когда возможно связывание с datacontext, так как существует меньше интерфейсов и меньше кода для поддержки.

по материалам blog

Ответ 4

И MVP, и MVVM являются производными от MVC (см. временные графики и способы их эволюции). Ключевое различие между ними - это зависимость, которую каждый уровень имеет на других уровнях, а также то, насколько они тесно связаны друг с другом.

MVC: библиотека Framework

Клиентская сторона Backbone.js, knockback.js, Spine.js, angular.js.

Серверная сторона ASP.NET MVC, Spring MVC, Ruby-on-Rails

MVP: Библиотека Framework

Клиентская сторона Riot.js, GWT

Серверная сторона ASP.NET, сервлеты JSP

MVVM: библиотека Framework

Клиентская сторона Knockout.js, Kendo (MVVM)

Серверная сторона WPF (Desktop) или Silverlight, приложения для Windows Phone (XAML), Adobe Flex

Итак, чтобы ответить на конкретный вопрос: да, кроме двухсторонней привязки в MVVM, ViewModel предоставляет Observable, что является основным преимуществом MVVM, который связывает двухсторонние данные.