Имеет ли смысл использовать паттерн MVVM в приложении Winforms?
Вот думаю написать простую админку для работы с объектами БД (добавить/удалить/отредактировать/посмотреть список). Сам писал только под WPF, но в запасниках есть проект на винформах, который успешно справлялся с подобной задачей. MVVM там не использовался: все обработчики в partial class.
Имеет ли практический смысл писать на винформах, как под WPF? Если я правильно понимаю, то от обработчиков событий в Code Behind никуда не деться (в WF вроде нет команд). Получается, эти обработчики будут использоваться для проксирования вызовов во вьюмодели?
В WPF вьюмодель обычно реализует интерфейс INotifyPropertyChanged. Для WF этот интерфейс вроде бы тоже актуален (т.е. может обновлять зависимые контолы). Но имеет ли это практический смысл для ПО уровня таблица сущности - форма сущности плюс несколько сводных табличек-отчетов.
В общем, было бы интересно услышать мнение людей с опытом поддержки WF и WPF приложений.
Нет, не стоит. Я например делал клиент сервервые приложения, где сервер был с гуишкой как раз на WinForms и крутился на windows server, а для клиентов делал "красивое", уже на wpf.
WinForms отличная, простая штука, позволяющая без лишней писанины и проектирования делать годные вещи. Очень много чего частоиспользуемого там реализовано уже с коробки и под свою задачу можно настроить написав 2 строчки кода, хотя подобное реализовать на WPF займет куда больше времени.
Кстате даже когда я впервые перешёл на WPF, то долгое время вообще не использовал mvvm и работал как с windows forms.
Нет, оно там просто не нужно - достаточно просто правильно структурировать приложение. В WF вполне достаточно просто разделить логику приложения и логику самого интерфейса. Нужен нестандартный контрол со своим поведением? Отпочковываем класс от Control и вперед. Логика самого интерфейса вполне нормально живет в самих классах элементов управления (в терминах MVVM это два в одном View + ViewModel). Например, реальный случай из практики: запилил WF приложение по выданному дизайну - его потестили и почти сразу дизайнер нарисовал полностью новый дизайн; ввиду увеличения фишечек, рюшечек и всего остального (а так же тормозов древнего легаси наследия WF, конечно же) - я просто перенес файлы с логикой из WF проекта в WPF проект в модели и запилил новый GUI на WPF.
WPF немного адаптирован для MVVM, но это не обязательно — масса примеров в родной документации не использует никакого MVVM. Так что я бы не связывал выбор использования MVVM с WPF.
Есть готовые библиотеки для WinForms, которые умеют делать легкий MVVM. Лично я, например, работал с DevExpress и на мой взгляд, из коробки он дает даже больше, чем WPF (например, есть встроенные сервисы работы с попап окнами). Так что использовать MVVM на WinForms не сложнее, чем на WPF.
И раз мы отделили вопрос MVVM от WPF/WF, нужно принципиально решать вопрос использовать ли MVVM в конкретном проекте.
И, собственно, вопрос использование MVVM имеет плюсы и минусы. Плюсы — сопротивление хаосу при массированных изменениях кода, уменьшение человеческого труда при тестировании. Минусы — больше кодинга (накладные расходы на раздельную реализацию VM + юнит-тесты), не устраняет ручное тестирование до конца. Использовать MVVM без юнит-тестов смысла особо не вижу — кодить больше, выгоды никакой.
Лично мое мнение — если нужна простая утилита «для себя», которую один раз написали и не трогают, я бы писал быстро (без MVVM и тестов). А если её будут менять, в том числе другие разработчики, а цена ошибки — деньги (например, если админятся данные клиентов по контрактам), то лучше MVVM и тесты.
