Ответ 1

Как говорит Брайан, здесь, возможно, есть два вопроса:

Должен ли я?

Меня попросил клиент сделать это. Они используют WPF (и MVVM) для своей работы в новом окне, но также имеют устаревшие приложения Winforms, которые иногда требуют поддержки и улучшения. У них никогда не было сценария, где "Ditch существующее приложение и переписать его в WPF" было жизнеспособным вариантом.

Для определенного набора улучшений для существующего приложения Winform (я оценил улучшения на 2 человеко-года, настолько довольно существенные), они были очень заинтересованы в том, что я применяю подход, который может уменьшить боль, если они захотят переместите приложение в WPF когда-нибудь в будущем. Итак, мы рассмотрели возможность создания MVVM-среды для Winforms в убеждении, что весь код в M и VM будет повторно использоваться, наступит день. В случае, если мы достигнем почти того - виртуальная машина будет нуждаться в настройке, но не в перезаписи.

Итак, есть реальный сценарий, в котором описывается, почему вы можете это сделать.

Могу ли я?

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

То, как мы это делали, это посмотреть на файл конструктора формы (т.е. вид) и разработать набор (3 или 4) пользовательских классов атрибутов, который определит привязку между ViewModel и элементом управления. Например:

[VmOneWayPropertyBinding("Info", "Text")]
private System.Windows.Forms.Label labelInfo;

Этот код в основном определил одностороннюю привязку между свойством Info в ViewModel и свойством labelInfo1.Text в форме. Мы также определили двухсторонние привязки и привязки команд, а также еще пару эзотерических привязок (похоже, мы допускаем привязку к ErrorProvider, и мы будем автоматически устанавливать с помощью IDataErrorInfo, например).

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

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

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

Некоторые вещи, которые мы рассмотрели на пути: ICommand (к сожалению, Microsoft запустила это в сборке, подобном WPF, поэтому нам пришлось определять наши собственные идентичные), Converters (ditto IValueConverter), IDataErrorInfo, INotifyPropertyChanged (оба, к счастью, определены в не WPF -специфические сборки). Все эти вещи действительно полезны, если вы хотите спуститься по маршруту MVVM. О, и получая свойства внутри контейнеров внутри контейнеров внутри...

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

Так это стоило? Ну, я могу просто сказать "Да, потому что мой клиент попросил меня сделать это, и они довольны результатом". Но, по правде говоря, это положительно сказалось, не в последнюю очередь потому, что люди с кодовым замком намного опережают. Код заканчивается в ViewModels по умолчанию, а просмотры почти бесплодны.

Ответ 2

Я думаю, что здесь есть два ответа... действительно один ответ на вопрос "Должен ли я" и один ответ на вопрос "Могу ли я".

Что касается "Могу ли я", это, безусловно, возможно. MVVM действительно просто полагается на представление, которое может привязываться к модели представления. Поскольку WinForms поддерживает привязку, это, безусловно, возможно. Возможно, вам понадобится написать код, чтобы сделать эту привязку более полезной в мире MVVM, но она (по крайней мере) теоретически возможна. Если бы это сработало, преимущества были бы очень хорошими, ИМО. Вы можете убедиться, что у вашего WinForms "View" не было поведения пользовательского интерфейса, за исключением создания визуальных объектов и их связывания (в коде, а не декларативном, как в XAML). Объекты WinForms очень трудно тестировать, где ViewModels очень легко тестировать.

Насколько ваш реальный вопрос: "Должен ли я", это становится гораздо более важным решением на уровне проекта. Каковы твои цели? Если вы хотите сделать достаточно сложную логику пользовательского интерфейса, вы можете хотя бы изучить ее. К счастью, однако, существуют и другие шаблоны (например, Model-View-Presenter), которые имеют больше поддержки сообщества, и вы также можете написать тестируемый класс "презентатор". Я считаю, что ViewModels значительно легче писать модульные тесты по сравнению с презентаторами, но я думаю, что это личное предпочтение.

Как и в стороне, шаблон MVVM является главным образом другим именем шаблона "Модель презентатора". Вы можете посмотреть, есть ли у кого-то успех с "Моделью презентатора" против пользовательских интерфейсов WinForms.

Удачи!

Ответ 3

Шаблон Model-View-ViewModel (MVVM) является шаблоном проектирования. По определению шаблон проектирования показывает общее решение в объектно-ориентированном мире, и это решение может применяться на различных платформах (WPF, WinForms, Java Swing и т.д.). Я согласен, что MVVM лучше всего использовать с WPF, потому что он использует возможности сильного связывания. Однако Windows Forms также поддерживает привязку данных.

Адаптер Windows Forms WAF показывает, как применять шаблон MVVM в приложении Windows Forms.

Ответ 4

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

Причина, по которой это может быть сделано в WPF, состоит в том, что WPF позволяет свободно связывать представление из viewmodel посредством привязки данных в xaml. Это позволяет ViewModel не знать ничего о представлении и все еще быть в состоянии работать. Это хорошая статья по основам MVVM, я считаю, что она прояснит несколько вопросов.

Ответ 5

MVVM Специально подходит для кода разметки + и беззаботной модели в WPF и Silverlight. Я бы не предложил его в приложение winforms, поскольку я считаю, что это будет излишним. Я не вижу никакой пользы от MVP в приложении winforms. Однако в WPF и silverlight это всегда предпочтительнее MVP.

Прочитайте в Интернете, что такое MVVM и почему это произошло. Это должно прояснить это.

Ответ 6

MVVM был специально создан для WPF, чтобы использовать возможности WPF, такие как привязки и команды. У Windows Forms нет этих функций (*), поэтому на самом деле не имеет смысла пытаться применить шаблон MVVM к приложению Windows Forms... Вместо этого вы должны использовать MVC или MVP.

(*) У него фактически есть базовая поддержка привязки данных, но не такая мощная, как в WPF...