Имеет ли смысл использовать паттерн MVVM в приложении Winforms?

Вот думаю написать простую админку для работы с объектами БД (добавить/удалить/отредактировать/посмотреть список). Сам писал только под WPF, но в запасниках есть проект на винформах, который успешно справлялся с подобной задачей. MVVM там не использовался: все обработчики в partial class.

Имеет ли практический смысл писать на винформах, как под WPF? Если я правильно понимаю, то от обработчиков событий в Code Behind никуда не деться (в WF вроде нет команд). Получается, эти обработчики будут использоваться для проксирования вызовов во вьюмодели?

В WPF вьюмодель обычно реализует интерфейс INotifyPropertyChanged. Для WF этот интерфейс вроде бы тоже актуален (т.е. может обновлять зависимые контолы). Но имеет ли это практический смысл для ПО уровня таблица сущности - форма сущности плюс несколько сводных табличек-отчетов.

В общем, было бы интересно услышать мнение людей с опытом поддержки WF и WPF приложений.
  • Вопрос задан
  • 188 просмотров
Решения вопроса 1
igolets
@igolets
Программист C#, MSSQL
  1. WPF немного адаптирован для MVVM, но это не обязательно — масса примеров в родной документации не использует никакого MVVM. Так что я бы не связывал выбор использования MVVM с WPF.
  2. Есть готовые библиотеки для WinForms, которые умеют делать легкий MVVM. Лично я, например, работал с DevExpress и на мой взгляд, из коробки он дает даже больше, чем WPF (например, есть встроенные сервисы работы с попап окнами). Так что использовать MVVM на WinForms не сложнее, чем на WPF.
  3. И раз мы отделили вопрос MVVM от WPF/WF, нужно принципиально решать вопрос использовать ли MVVM в конкретном проекте.
  4. И, собственно, вопрос использование MVVM имеет плюсы и минусы. Плюсы — сопротивление хаосу при массированных изменениях кода, уменьшение человеческого труда при тестировании. Минусы — больше кодинга (накладные расходы на раздельную реализацию VM + юнит-тесты), не устраняет ручное тестирование до конца. Использовать MVVM без юнит-тестов смысла особо не вижу — кодить больше, выгоды никакой.


Лично мое мнение — если нужна простая утилита «для себя», которую один раз написали и не трогают, я бы писал быстро (без MVVM и тестов). А если её будут менять, в том числе другие разработчики, а цена ошибки — деньги (например, если админятся данные клиентов по контрактам), то лучше MVVM и тесты.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
VoidVolker
@VoidVolker
Разработчик ПО и IT-инженер
Нет, оно там просто не нужно - достаточно просто правильно структурировать приложение. В WF вполне достаточно просто разделить логику приложения и логику самого интерфейса. Нужен нестандартный контрол со своим поведением? Отпочковываем класс от Control и вперед. Логика самого интерфейса вполне нормально живет в самих классах элементов управления (в терминах MVVM это два в одном View + ViewModel). Например, реальный случай из практики: запилил WF приложение по выданному дизайну - его потестили и почти сразу дизайнер нарисовал полностью новый дизайн; ввиду увеличения фишечек, рюшечек и всего остального (а так же тормозов древнего легаси наследия WF, конечно же) - я просто перенес файлы с логикой из WF проекта в WPF проект в модели и запилил новый GUI на WPF.
Ответ написан
Комментировать
yarosroman
@yarosroman Куратор тега C#
C# the best
А что сразу не делать проект на WPF? Тем более он затачивался под MVVM. MVVM в WinForms можно, но немного с костылями.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы