Как выбрать между WinForms, WPF и WinUI - практическая таблица решений

При создании настольных приложений Windows на C# / .NET незаметно, но регулярно возникает вопрос: что выбрать - WinForms, WPF или WinUI.

Здесь опасно выбирать по расплывчатым критериям вроде:

• «WinUI, потому что это самое новое»;
• «WinForms, потому что к нему больше всего привыкли»;
• «WPF, потому что он кажется чем-то средним».

На практике оси, на которые стоит смотреть, гораздо конкретнее.

• Это новая разработка или продолжение существующих активов?
• Экраны в основном формы ввода, или нужна выразительность?
• Является ли современный, характерно «Windows»-стильный UI сам по себе ценностью продукта?
• Как обстоят дела с распространением, обновлением и корпоративной эксплуатацией?
• Команда ближе к культуре Designer-а или к культуре XAML / MVVM?

В этой статье мы аккуратно сведём всё это в единую, легко читаемую таблицу решений. Отметим, что в этой статье под WinUI в основном подразумевается WinUI 3 + Windows App SDK. ¹²

Кроме того, все эти три технологии предназначены исключительно для Windows. Если в поле зрения есть macOS / Linux, сама постановка задачи принципиально иная. ³⁴¹

1. Сначала вывод (одной фразой)

Если сформулировать довольно грубо, но удобно для практики, получится так.

• Если у вас большое существующее приложение на WinForms, в первую очередь стоит рассмотреть продолжение работы на WinForms
• Если у вас большое существующее приложение на WPF, в первую очередь стоит рассмотреть продолжение работы на WPF
• Для нового небольшого-среднего внутреннего инструмента, ориентированного на стандартные элементы управления и экраны ввода, который нужно сделать быстро, WinForms по-прежнему очень силён ³⁵
• Для нового средне-крупного бизнес-приложения со множеством экранов, где важно грамотно использовать привязку данных, стили, шаблоны, команды и MVVM, чаще всего самый безопасный выбор - WPF ⁴⁶⁷
• Для нового Windows-эксклюзивного продукта, где современный Windows UI, Fluent и актуальный опыт Windows напрямую определяют ценность продукта, сильным кандидатом становится WinUI ¹²
• Если вы просто хотите использовать новейшие Windows API, WinUI не обязателен. WPF / WinForms тоже могут использовать возможности Windows App SDK ²⁸⁹¹⁰
• Выбирать, исходя из предпосылки «потом постепенно подмешаем WinUI», немного опасно. История с поэтапной миграцией на деле грязнее, чем кажется ¹⁰¹¹

Иными словами, в целом получается следующее.

1. Если существующие активы велики, в первую очередь сохраняем эту линейку
2. Для новой разработки, где нужно быстро собрать стандартные формы - WinForms
3. Для новой разработки долгоживущего Windows-бизнес-приложения - WPF
4. Для новой разработки, где сам современный Windows UI - требование, - WinUI
5. Если нужен только Windows App SDK, не переходить сразу целиком на WinUI

Выбор фреймворка - это одновременно выбор UI-технологии и выбор распространения, эксплуатации, затрат на обучение и затрат на миграцию. Если решать это, опираясь только на «новое / старое», это тихо, но неприятно аукнется позже.

2. Три технологии, о которых идёт речь в этой статье

Сначала немного выровняем терминологию.

WinForms в Microsoft Learn описывается как фреймворк с элементами управления, графикой, привязкой данных и пользовательским вводом, который позволяет удобно создавать приложения с помощью drag-and-drop Designer-а Visual Studio. ³

WPF - это высоковыразительный UI-фреймворк, включающий векторную отрисовку, независимую от разрешения, XAML, привязку данных, стили / шаблоны, 2D / 3D и анимацию. ⁴

WinUI - часть Windows App SDK, современный UI-фреймворк для сегодняшней Windows, ориентированный на высокий DPI, современный ввод, плавную анимацию и опыт в стиле Fluent. ¹² При этом он вполне обычно поддерживает привязку данных / MVVM. ¹²

Здесь важно, что Windows App SDK и WinUI - не одно и то же. WinUI - это UI-часть Windows App SDK, но сам Windows App SDK можно добавить и к существующим приложениям на WPF / WinForms / Win32. ²¹⁰

Поэтому:

• использовать WinUI;
• использовать возможности Windows App SDK

выглядят похоже, но это разные решения. Когда это перемешивается, разговор в переговорной начинает слегка «затуманиваться».

3. Таблица решений на одну страницу

Сначала приведём таблицу, наиболее удобную для практики.

Одной этой таблицы в целом достаточно, но остаются два момента, вызывающих затруднения.

1. Для нового Windows-бизнес-приложения - склоняться к WinForms или к WPF?
2. Есть существующий WPF / WinForms - стоит ли переходить на WinUI?

Эти два момента легче оценить, глядя на сравнительную таблицу ниже.

4. Сравнительная таблица по критериям

Это не официальная таблица превосходства, а сравнение, сильно ориентированное на практику.

Смысл этой таблицы не в том, что сильнее всего, а в том, что создаёт наименьшее трение.

Например, если у вас:

• внутренний инструмент настроек;
• экран настройки оборудования;
• список, детали, поиск, настройки, кнопки;
• важнее не внешний вид, а стабильность эксплуатации и скорость доработки, -

то WinForms и сегодня остаётся вполне разумным выбором.

И наоборот, если у вас:

• много экранов;
• частая смена состояний отображения;
• желание разделить View и логику;
• желание естественно связать изменения данных с UI;
• желание управлять UI через стили / шаблоны, -

то WPF срабатывает очень хорошо. ⁶⁷

А если у вас:

• желание опираться на облик, характерный для Windows 11;
• желание по-настоящему задействовать Fluent;
• предпосылка высокого DPI, touch и современных API окон;
• новый Windows-эксклюзивный продукт, где важно и впечатление от UI, -

то естественным выбором становится WinUI. ¹²

5. Какие проекты подходят каждой технологии

5.1 WinForms

К WinForms часто относятся незаслуженно легкомысленно, но по одному-единственному критерию - быстрое создание бизнес-экранов на стандартных элементах управления - он и сегодня остаётся весьма серьёзным конкурентом. ³⁵

Особенно он подходит для таких проектов:

• внутренние инструменты настроек;
• экраны настроек для оборудования, измерительных приборов, инструментов мониторинга;
• административные экраны, экраны поиска, список + детали;
• проекты с большими существующими активами на WinForms;
• команды с сильной культурой сборки экранов через Designer.

Сила WinForms в том, что, не привнося сложной философии, можно достаточно быстро получить экран, близкий к готовому продукту. Формы, кнопки, метки, текстовые поля, таблицы данных. Если это ваше основное поле боя, вы можете весьма успешно на нём воевать.

Однако слабые места тоже очевидны.

• Желание широко унифицировать внешний вид всего приложения
• Желание управлять UI через стили и шаблоны
• Желание обрабатывать сложные изменения состояния преимущественно через привязку данных
• Желание аккуратно отделить логику экрана

Здесь WPF и WinUI выглядят более естественным выбором.

Крупное приложение на WinForms, стоит немного расслабиться, легко превращается в джунгли обработчиков событий. Поэтому, выбирая WinForms, лучше сразу зафиксировать хотя бы следующее:

• держать ответственность каждого экрана небольшой;
• разбивать на UserControl;
• сознательно выдерживать границу, аналогичную Presenter / ViewModel;
• не размазывать бизнес-логику по обработчикам событий экрана.

Также в практике очень важно: желание использовать Windows App SDK не является причиной отказываться от WinForms. Есть официальный путь добавления возможностей Windows App SDK к существующему приложению на WinForms. ⁹¹⁰

То есть с WinForms доступен такой выбор:

• оставить UI как есть;
• модернизировать только нужные функции Windows.

Это вполне реалистичный компромисс.

5.2 WPF

Если рассматривать его как .NET UI для настольных приложений Windows, WPF - это наиболее сбалансированное ядро. ⁴

Его сильные стороны очевидны.

• Экраны можно декларативно описывать на XAML
• Сильная привязка данных (Data Binding)
• Доступны Style / Template
• Доступны Command
• Легко разделить View и логику
• Легко организовывать средние и крупные наборы экранов

В официальной документации WPF привязка данных тоже описана как центральная функция WPF, а команды - как механизм, отделяющий ввод от логики выполнения. ⁶⁷

Поэтому он подходит, например, для таких проектов:

• бизнес-приложения со множеством экранов;
• много списков, деталей, редактирования, поиска, отображения статуса;
• Windows-приложения, которые долго сопровождают несколько человек;
• желание разделить View и логику;
• желание заранее разделить ответственность за внешний вид и поведение с прицелом на будущую доработку;
• экраны, которые в WinForms быстро становятся тяжёлыми.

Когда сомневаетесь при выборе для нового Windows-эксклюзивного бизнес-приложения, WPF и сегодня остаётся безопасным первым кандидатом. Отбрасывать его словами «WPF устарел, поэтому не годится» - несколько грубо.

Наоборот, если у вас:

• есть существующие активы на WPF;
• есть существующая экспертиза в XAML / MVVM;
• Fluent не является абсолютным приоритетом;
• но хочется спроектировать UI аккуратнее, чем в WinForms, -

то WPF вполне обычно оказывается самым разумным выбором.

Конечно, у WPF есть и свои особенности.

• Чрезмерно усложнённый XAML становится трудночитаемым
• Погружение в собственные элементы управления и «ад шаблонов» утяжеляет сопровождение
• Уклон в религию «делаем всё через Binding» тоже может, наоборот, затруднить понимание

Это действительно так, но дело не столько в том, что WPF плох, сколько в том, что выразительный инструмент даёт сильную отдачу при небрежном обращении.

В WPF тоже можно добавить часть возможностей Windows App SDK. То есть существует путь модернизировать функции Windows, оставаясь на WPF. ⁸¹⁰

Поэтому вместо

• полного отказа от WPF ради сплошной миграции на WinUI

на практике чаще выигрывает подход:

• подтянуть WPF к текущему .NET;
• добавить только нужные функции Windows через Windows App SDK;
• наводить порядок в архитектуре начиная с крупных новых функций.

5.3 WinUI

WinUI - современный фаворит при создании нового Windows-эксклюзивного приложения. ¹²

Официально он позиционируется как:

• оптимизированный под новейшее оборудование и ввод;
• высокий DPI;
• плавная анимация;
• часть Windows App SDK.

¹

Поэтому он подходит для таких проектов:

• новый Windows-эксклюзивный продукт;
• где важны само впечатление от UI и опыт использования;
• желание прямолинейно использовать Fluent;
• желание ориентироваться на актуальное состояние Windows 11;
• предпосылка новых API окон и актуального опыта Windows.

Проекты, где есть по-настоящему веская причина выбрать WinUI, - это в основном не проекты «выглядит по-новому», а проекты «хотим встроить в продукт сегодняшний опыт Windows».

При этом есть и предостережения.

5.3.1 WinUI - это не «просто новый WPF»

Из-за использования XAML он выглядит похожим, но различаются:

• базовые API;
• набор элементов управления;
• структура проекта;
• подход к развёртыванию / упаковке;
• способ взаимодействия с Windows App SDK.

Иными словами, рассматривать его как беспечную замену WPF несколько опасно.

5.3.2 Выбор WinUI выдвигает вопрос распространения на первый план

Приложения на WinUI 3 по умолчанию упакованы (packaged). При этом сам Windows App SDK работает и с packaged, и с unpackaged-вариантами. ¹³¹⁴²

Здесь важно заранее решить:

• как распространять приложение;
• как устанавливать среду выполнения;
• нужна ли package identity;
• внутреннее распространение, Store, MSIX или традиционный путь EXE / MSI.

Распространение важно и для WinForms / WPF, но у WinUI этот вопрос выходит на первый план раньше. Казалось, что выбираете UI, а на деле выбрали стратегию распространения - в этом небольшая сложность данного мира.

5.3.3 «Постепенно подмешивать WinUI в существующий WPF / WinForms» - сначала стоит проверить на практике

Здесь ожидания легко разрастаются. Однако собственный FAQ Microsoft, по сути, говорит, что WinUI зачастую нельзя использовать, если вы не готовы полностью перейти на другой UI-фреймворк. Что касается XAML Islands, официальная документация показывает путь встраивания в существующие настольные приложения, но в примечаниях к выпуску Windows App SDK 1.4 указано, что на данный момент это в основном протестировано в приложениях на C++, а удобных элементов-обёрток для WPF / WinForms не предусмотрено. ¹⁰¹¹

Иными словами:

• «похоже, можно мигрировать поэтапно»;
• «похоже, можно заполнять постепенно»

привлекательны как концепция, но прежде чем делать их основной стратегией проекта, стоит проверить на небольшом масштабе.

WinUI лучше всего работает, когда вы:

• начинаете с нуля;
• создаёте опыт для Windows-эксклюзивного продукта.

Наоборот, в роли площадки для полной замены существующего WPF / WinForms он требует обоснования и проверки.

6. Частые ошибки при выборе

6.1 «WinUI, потому что это новейшее»

Это понятно, но довольно опасно.

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

• Современный опыт Windows - это ценность продукта?
• Хочется прямолинейно использовать Fluent?
• Это новый продукт?
• Готовы ли вы принять предпосылки по распространению / эксплуатации?

Если ответ «да», WinUI - сильный кандидат. Если же аргумент сводится лишь к «кажется, у этого есть будущее», обоснование затрат слабое.

6.2 «Раз хотим Windows App SDK, значит обязаны перейти на WinUI»

Это распространённое заблуждение, и оно неверно.

Windows App SDK можно добавить и к существующим приложениям на WPF / WinForms. Официальный FAQ тоже поясняет, что приложения на WPF / MFC / WinForms могут использовать API Windows App SDK, не связанные с WinUI. ¹⁰⁸⁹

Например, такие функции, как:

• App Lifecycle;
• Windowing;
• Toast Notifications,

в ряде случаев можно внедрить, сохранив текущий UI. ¹⁰

6.3 «WPF / WinForms уже закончились»

Здесь тоже не стоит рубить сплеча.

И WinForms, и WPF продолжают получать документацию и пути миграции на текущем .NET и официально считаются действующими UI для настольных приложений Windows. ³⁴

Особенно в бизнес-приложениях следующее нередко весит больше, чем новизна UI-фреймворка:

• существующие активы;
• сторонние элементы управления;
• количество экранов;
• отчёты и печать;
• интеграция с оборудованием;
• процедуры распространения.

6.4 «Раз уж так, лучше полностью переписать»

Полное переписывание ближе к бизнес-решению, чем к выбору технологии.

Если существующее приложение уже есть, в первую очередь стоит проверить следующее.

1. Что на самом деле вызывает боль?
2. Это проблема UI или проблема архитектуры?
3. Не являются ли настоящей нагрузкой зависимые DLL / COM / OCX / отчёты / распространение?
4. Можно ли решить проблемы, не меняя весь UI целиком?

Переписывание UI выглядит эффектно, но и стоит соответственно. Более того, даже с новым обликом окружающая сложность в основном никуда не девается.

6.5 «Потом как-нибудь решим через XAML Islands»

Эту надежду можно понять. Но безопаснее не рассматривать это как спасательную шлюпку с самого начала. ¹⁰¹¹

Для поэтапной миграции сначала стоит на небольшом масштабе проверить:

• какие элементы управления вы хотите встроить;
• что будет с фокусом, вводом, DPI, темой;
• действительно ли эта конфигурация хостинга остаётся стабильной.

7. Как смотреть на вопрос, если есть существующее приложение

Здесь существующее приложение важнее новой разработки.

7.1 Если есть существующий WinForms

Прежде чем сразу прыгать на WinUI, проверьте следующее.

• Можно ли подтянуть к текущему .NET?
• Нужен ли переход на 64-бит?
• Можно ли навести порядок в async / await, обработке исключений, настройках, логировании?
• Можно ли повысить сопровождаемость за счёт разбиения экранов или выделения UserControl?
• Можно ли добавить только нужные функции Windows через Windows App SDK?

То, что выглядит как проблема WinForms, нередко на деле оказывается просто:

• смешением экранов и логики;
• небрежными границами потоков;
• скученностью ответственности за настройки / файлы / COM / БД.

В таком случае переезд на WinUI лишь переименовывает проблему, но не решает её.

7.2 Если есть существующий WPF

WPF позволяет легко использовать существующие активы.

• Активы XAML
• Binding
• Style / Template
• Command
• MVVM

Причина отказаться от всего этого должна быть довольно явной.

Например, если:

• вы хотите полностью обновить UI продукта;
• Fluent должен стать основной осью;
• новый модуль выделяется как отдельный продукт;
• вы хотите двигаться к новому опыту как Windows-эксклюзивный продукт, -

это может стать основанием для рассмотрения WinUI. Но простое «потому что WPF устарел» - слабый аргумент.

7.3 То, что действительно тяжело, часто не связано с UI

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

• ActiveX / OCX;
• COM interop;
• собственные отчёты;
• печать;
• интеграция с Excel / Office;
• нативные DLL;
• перекосы между 32-бит и 64-бит;
• установщики, права доступа, обновления, подпись.

Если недооценить это, даже красивый UI не облегчит проект в целом.

Поэтому при миграции существующего приложения сначала стоит провести инвентаризацию границ зависимостей целиком, а не смотреть только на UI-фреймворк.

8. Пять вопросов, на которые стоит ответить, если вы всё ещё не определились

Если в итоге вы всё ещё не можете решить, по порядку задайте себе эти пять вопросов.

8.1 Велики ли существующие активы?

• Велики → в основном сохраняем существующую линейку
• Малы / отсутствуют → переходим к новому выбору

8.2 Обязателен ли для этого приложения «современный, характерно Windows-стильный опыт»?

• Обязателен → WinUI - сильный кандидат
• Не особо → проверьте, достаточно ли WPF / WinForms

8.3 Экраны в основном стандартные формы, или нужна выразительность в духе XAML?

• В основном стандартные формы → WinForms
• Важны стили / шаблоны / Binding / MVVM → WPF

8.4 Нужно полное обновление UI или добавление функций Windows?

• Полное обновление UI → рассмотреть WinUI
• Только добавление функций → сначала рассмотреть текущий WPF / WinForms + Windows App SDK

8.5 Можете ли вы заранее объяснить, как будет устроено распространение / обновление / эксплуатация?

• Пока неясно → для WinUI заранее проработать упаковку / развёртывание
• Хочется сильно опираться на существующую эксплуатацию → у WPF / WinForms обычно меньше трения

Эти пять вопросов заметно сужают выбор. Если в конце подвести грубый итог, получается так:

• Быстро собрать внутреннюю форму → WinForms
• Долгоживущее Windows-бизнес-приложение → WPF
• UI нового современного Windows-продукта → WinUI
• Сохранить существующее, модернизировав только функции Windows → текущий фреймворк + Windows App SDK

9. Итог

Выбор между WinForms, WPF и WinUI - это не игра «выстроить по новизне и взять крайний справа».

В первую очередь стоит посмотреть на эти четыре вещи.

1. Где находятся существующие активы
2. Экраны ориентированы на формы или на выразительность
3. Является ли современный, характерно Windows-стильный UI требованием продукта
4. Как будет устроено распространение / обновление / эксплуатация

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

• Большое существующее хозяйство на WinForms → в первую очередь продолжаем на WinForms
• Большое существующее хозяйство на WPF → в первую очередь продолжаем на WPF
• Новая разработка, ориентированная на стандартные формы → WinForms
• Новое средне-крупное Windows-бизнес-приложение → WPF
• Новая разработка, где само требование - современный Windows-опыт → WinUI
• Если нужен только Windows App SDK, не переходить сразу целиком на WinUI

Больше всего стоит избегать этих трёх подходов:

• отбрасывать, потому что старое;
• выбирать, потому что новое;
• начинать с расчёта «как-нибудь разберёмся по ходу».

Настольная Windows - это мир, где активы, распространение, эксплуатация и зависимости весят больше, чем внешний вид. Поэтому и при выборе технологии обычно выигрывает ориентация на низкое трение, а не на «блеск».

10. Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

В чём разница между WinUI 3 и WPF?

Оба используют XAML, но WinUI - это не «просто более новый WPF». Различаются базовый API, набор элементов управления, структура проекта, подход к развёртыванию и упаковке, а также способ взаимодействия с Windows App SDK. WPF - это UI-фреймворк для средних и крупных бизнес-приложений с векторной отрисовкой, независимой от разрешения, привязкой данных, стилями/шаблонами и командами. WinUI - современный UI-фреймворк как часть Windows App SDK, ориентированный на Fluent, высокий DPI и актуальный опыт работы с Windows. Рассматривать его как беспечную замену WPF опасно.

Что выбрать для новой разработки - WinForms, WPF или WinUI?

Всё зависит от характера экранов и требований продукта. Для небольшого-среднего внутреннего инструмента, ориентированного на стандартные элементы управления и формы ввода, который нужно сделать быстро, WinForms по-прежнему очень силён. Для средне-крупного бизнес-приложения со множеством экранов, где важны привязка данных, стили, шаблоны и MVVM, чаще всего самый безопасный выбор - WPF. Для нового Windows-эксклюзивного продукта, где Fluent и современный опыт Windows напрямую определяют ценность продукта, сильным кандидатом становится WinUI. Если существующие активы велики, в первую очередь стоит рассмотреть продолжение работы в рамках этой же линейки.

WPF и WinForms уже устарели?

Не стоит списывать их небрежно. И WinForms, и WPF продолжают получать документацию и пути миграции на текущем .NET и официально считаются действующими UI для настольных приложений Windows. Особенно в бизнес-приложениях существующие активы, сторонние элементы управления, отчёты и печать, интеграция с оборудованием и процедуры распространения нередко весят больше, чем новизна UI-фреймворка. Нередки случаи, когда даже для новой разработки WinForms или WPF оказываются выбором с наименьшим трением.

Нужно ли переходить на WinUI, чтобы использовать новейшие возможности Windows?

Нет. Windows App SDK и WinUI - не одно и то же: WinUI - это UI-часть Windows App SDK. Сам Windows App SDK можно добавить и в существующие приложения на WPF / WinForms / Win32, а такие функции, как App Lifecycle, Windowing и Toast Notifications, в ряде случаев можно внедрить, сохранив текущий UI. То есть существует путь модернизации только нужных функций Windows при сохранении существующего WPF / WinForms, и полная миграция UI не обязательна.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.