Композитное руководство для WPF: MVVM против MVP

Я смущен. Может быть, вы можете мне помочь:)

Я следил за руководством CAG и нашел шаблон MVP очень естественным для меня. Предположим, что у меня есть готовая к UI модель (например: реализует INotifyPropertyChanged), я использую презентатор для привязки этой модели к представлению (ведущий знает интерфейс представления), сохраняя мой код-Behind как можно меньшим, чем обработка только привязок ( Model и Commands) (или методы) или события для элементов управления, которые не имеют ICommand, и в этом случае немедленно делегируются ведущему.

Через некоторое время я обнаружил шаблон MVVM, и до сих пор он ускользает от меня. Насколько я могу судить по моему подходу, я бы использовал MVVM только тогда, когда моя модель не была готовой к использованию. Но было бы разумнее держать ведущего и просто использовать новую модель, я не понимаю, что я потеряю при таком использовании. Я знаю, что чего-то не хватает, но что это такое:).
Также, когда ваш просмотр является общим и может обрабатывать многие виды моделей (например, в PropertyGrid). ViewModel рекомендуется использовать с DataTemplate, но в этом случае вы просто не можете создать шаблон для каждого объекта в вашей модели, его просто нужно исследовать во время выполнения, что вы бы порекомендовали?
Во время просмотра Джоша Смита, говорящего о MVVM в screencast, у меня появилось ощущение, что повторное отображение модели в ViewModel нарушает DRY (не повторяйте себя), неужели это действительно неизбежно? это меня нисколько не удивляет, что он спорит об этом в сравнении с пламенем ADO.Net Динамические метаданные данных Data Data Data Now сегодня.

Надеюсь, что это было достаточно ясно

Спасибо

Ariel

Ответ 1

Что касается № 3, многие люди будут использовать аргумент "другой уровень косвенности", заявив, что изменения в модели не повлияют на представление. Хотя это технически правильно, это не настоящая причина делать что-то вроде этого.

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

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

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

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

Независимо от того, как это происходит без DRY, форсирование типов WCF или типов LINQ to SQL (или любого другого вашего любимого ORM) для реализации INotifyProperyChanged хуже.

Ответ 2

Ad.3. Может показаться, что вы повторяете себя, выставляя Model в ViewModel, но то, что вы действительно делаете, - это абстрагирование модели, так что View знает только об этой абстракции (View знает только о ViewModel).

Это связано с тем, что изменения в Модели не должны нарушать представление. Кроме того, ваша Модель может быть реализована как множество различных сервисов, которые получают данные из разных источников. В этом случае вам не хотелось бы, чтобы View узнал обо всех них, поэтому вы создаете еще одну абстракцию - ViewModel.

Ответ 3

Кроме комментариев выше. Я хотел бы поделиться своим личным пониманием разницы.

Обычно в MVP есть интерфейс View, например. IView, чтобы абстрагировать фактические представления и привязать данные к этим фактическим представлениям. В MVVM вместо этого вы обычно используете DataContext для фактического представления, например. пользовательский элемент управления XAML, чтобы выполнить привязку данных, которая похожа на IView в MVP. Так что скажем, неточно, привязка похожа на оба шаблона.

Основное отличие заключается в части Presenter vs ViewModel. Модель просмотра очень отличается от ведущего, который является мостом для обмена данными между пользовательским интерфейсом и моделью. На самом деле это то, что означает его название, модель представления. Данные, представленные в ViewModel, в основном для процесса пользовательского интерфейса. Поэтому из моего понимания, в MVVM, ViewModel является абстракцией представлений. В противоположность этому, MVP использует в основном IView для абстрактных представлений. Так что, как правило, в MVVM есть несколько слоев, чем MVP, и поэтому вы можете писать меньше кода для выполнения той же работы в MVVM:

MVVM: Model - ViewModel (представляет фактические представления, то есть пользовательский интерфейс) - Фактические представления

MVP: Model - Presenter (мост для обмена данными между моделью и пользовательским интерфейсом) - IView (представляет собой фактические представления, то есть пользовательский интерфейс) - Фактические представления

Преимущество MVVM над MVP в основном основано на следующих двух замечательных функциях в продуктах Microsoft,

Команда в WPF. Он может быть avilable в Silverlight в будущем, хотя уже есть некоторые реализации, которых нет в среде выполнения Silverlight
DataContext в WPF и Silverlight.

Ответ 4

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

Я не совсем уверен, что вы просите во втором пункте. VM не является представлением (или знает представления), и для меня DataTemplate определяет способ отображения объекта. Я помещаю свои DataTemplates в ResourceDictionary, который определенно принадлежит в представлении. Единственными битами WPF 'stuff' в моем уровне VM являются команды.

Мне нужно немного больше информации, чтобы ответить на ваш третий вопрос. Возможно, он ответит сам, если вы копаете немного глубже в MVVM.

Вот ссылка, которая может помочь вам

Удачи.