У меня есть некоторые вопросы о шаблоне MVVM

Question

Меня зовут Хесус из Испании, я разработчик .NET, и я только что открыл эту прекрасную сеть несколько дней назад.

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

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

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

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

Я также видел, что если вам нужно событие, это похоже на MVP; делегирование события ведущему/View-Model, то есть если это не задание для представления (например, обновление пользовательского интерфейса).

С другой стороны, View-Model не имеет ссылки на View, поэтому мне приходится играть сложнее с привязкой данных.
Вы должны использовать DelegateCommands (это то же самое, что и RelayCommands, верно?).

Uhm ... еще вопросы ... Можно ли использовать одну и ту же модель View с двумя видами/пользовательскими элементами управления?

Ох ... Вчера я столкнулся с проблемой, когда играл в MVVM.
Я создал CommandReference моей команды для привязки ключа, и я присвоил эту ссылку свойству команды моей кнопки, ну, CanExecuted работал в первый раз, но он не обновлял свойство IsEnabled, когда значение CanExecuted было истинным , Я исправил его, привязывая команду непосредственно к кнопке и не используя ссылку. Возникает вопрос: почему какой-то код связывает ссылку с объектами и почему другой код привязывает команду напрямую?

Что мне нужно знать о MVVM? (Вчера я видел что-то, называемое прикрепленным поведением, но я не знаю, что это такое).

Я переписываю приложение для заметок, которое я разработал с использованием MVP, но теперь с MVVM. Я заменил события командами (используя DelegateCommand), устранит ссылки на представления в Model View, и я думаю, что все потому, что примеры, которые я видел MVVM, очень похожи на MVP.

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

Спасибо, и в будущем я буду помогать следующей MVVM послушников :)

Answer 1

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

• MVVM не обязательно является вариацией MVP. Сам MVP является неоднозначным, загруженным термином. Мартин Фаулер сделал это справедливо по splitting it into two patterns. MVVM стоит сам по себе, но разделяет некоторые концепции с шаблонами MVP. Как и все шаблоны пользовательского интерфейса, он стремится как можно больше отделить логику представления от бизнес-логики. Что MVVM делает это отличается от MVP, он создает модель исключительно для целей презентации (или presentation model). Это отличается от того, как шаблоны MVP решают проблему разделения.
  • Passive View - С пассивным видом вид никогда не видит модель.
  • Supervising Controller - MVVM намного ближе к шаблону диспетчерского контроллера, чем к пассивному виду. Единственная реальная разница здесь может заключаться в том, что MVVM явно создает модель только для представления (отсюда и термин «View Model»)
• ViewModel не имеет ссылки на представление, поскольку он служит в качестве модель для данных представления. Это подходящая абстракция. Если бы он также ссылался на представление, у вас была бы двусторонняя зависимость, которая создавала бы дополнительную связь. Кроме того, сам ViewModel не имеет реальной причины знать о представлении. Его единственная задача - отвлечь модель (фактическую бизнес-модель) от представления.
• DelegateCommands vs. RelayCommands - Я считаю, что вы используете технологию здесь, поэтому я не могу ответить на этот вопрос хорошо.
• Вы не должны проектировать ViewModel для нескольких видов. Это только создает сложность, так как если вы измените представление, вам придется исследовать, какие ViewModels могут быть затронуты и изменить их. Это может привести к каскадному эффекту. Ваше поведение должно быть в бизнес-модели, а не в ViewModel, поэтому ViewModel должен содержать только логику перевода и обработки событий.
• Было бы неплохо, однако, иметь отношение ViewModel 1: 1 к UserControl, поскольку UserControls должны быть в состоянии действовать как автономные единицы на вашем экране.
• Что касается других вопросов, связанных с конкретной технологией, извините, у меня нет ответа. Я могу предположить, однако, что вы внимательно прочитали ссылки, которые я включил для Passive View, Supervising Controller и Presentation Model. Предоставляют некоторый контекст шаблонам пользовательского интерфейса и являются нейтральными по технологиям.

Важно помнить, что, хотя MVVM подходит для решения проблем, связанных с использованием WPF, это не характерный для технологии шаблон. Если вы слишком глубоко погрузитесь в конкретную реализацию, не понимая основополагающей философии, вы можете сделать некоторые очень большие ошибки на раннем этапе и только обнаружить их после того, как стало слишком поздно. К сожалению, MVVM не является хорошо документированным образцом, и вы правы, когда заявляете, что у каждого есть своя идея о том, что это такое.

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

EDIT

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

Answer 2

Вам действительно не нужно использовать RelayCommand. Все, что вам действительно нужно сделать, это реализовать интерфейс ICommand на объекте. В каркасе SoapBox Core я определил интерфейс ICommandControl и все кнопки ViewModels и т. Д., Реализующие это. Существует также класс AbstractCommandControl, который вы можете использовать для его реализации.