Илья Голец

Триггеры, к сожалению, напрямую не предназначены для вызова кода. Но код можно вызывать косвенно. Навскидку могу привести следующие варианты:

1. DataTrigger может биндится через конвертер, соответственно, будет вызываться код конвертера с передачей данных из модели. Пример https://itecnote.com/tecnote/c-wpf-calling-method-...
   
2. EventTrigger может запускать TriggerAction. Можно написать свой TriggerAction и этот код будет вызываться по триггеру. Пример https://putridparrot.com/blog/a-simple-wpf-trigger...
   
3. Ну и по-простому можно триггером выставлять свойство контрола, а изменение свойства обрабатывать обработчиком.
   

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 и тесты.