Ответ 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 по умолчанию, а просмотры почти бесплодны.