WinForms/WPF/WinUIの選び方の知識マップ(知識グラフ)
WinForms・WPF・WinUIをどう選ぶかを、新規開発か既存資産の延長か、画面が標準フォーム中心か表現力重視かという軸で整理する記事で、標準コントロール中心の業務アプリにはWinForms、データバインディングとMVVMを活かす中〜大規模業務アプリにはWPF、Fluentや最新のWindows体験が製品価値に直結する新規Windows専用製品にはWinUIを推奨する。WinUIはWindows App SDKのUIフレームワーク部分であり、既定でMSIXパッケージとpackage identityを前提とする一方、Windows App SDK自体は既存のWPF/WinForms資産にも機能追加できるためUI全面移行は必須でないとし、XAML Islandsによる段階移行は主戦略にする前に小さく検証すべきだと注意を促す。
Windows Forms
デスクトップGUIアプリケーションを構築するための.NET/.NET FrameworkのUIフレームワーク。
WPF
XAMLでUIを宣言的に記述する、Windows専用のデスクトップUIフレームワーク。ベクターベースの描画とデータバインディングを特徴とする。
WinUI(Windows App SDK)
Windows App SDKベースのUIフレームワーク。Windows 11のモダンなUIに沿った外観と、Microsoft Store/MSIXとの親和性を持つ。動作対象はWindows 10 バージョン1809(ビルド17763)以降で、Windows 11専用ではない。
XAML
画面の構造を宣言的に書くためのXMLベースのマークアップ言語。WPFとWinUIが使う。
データバインディング
画面のプロパティとデータ側のプロパティを結び付け、片方が変わればもう片方も追随させる仕組み。
MVVM(Model-View-ViewModel)
画面(View)、画面用の状態とコマンド(ViewModel)、業務ロジックとデータ(Model)に分ける設計パターン。
Windows App SDK
WinUIを含む、今のWindows向け開発ライブラリ群。UI以外の機能もあり、WPF・WinForms・Win32の既存アプリにも追加できる。
MSIX
package identityを持つ、Windowsのモダンなアプリパッケージング形式。
package identity
MSIXなどのパッケージが持つ、Windowsが認識する一意の識別子。名前、バージョン、アーキテクチャ、ResourceId、発行元という5つの組で構成される。
パッケージID
外部の場所を指すpackaged(sparse package)
既存のインストーラーをそのまま使いながら、実行ファイルにpackage identityだけを付与できるpackagingモデル。
unpackaged app
MSIXなどのパッケージを使わず、従来どおりフォルダに実行ファイルを置く形で配布されるアプリ。
アンパッケージアプリ
従来型のデスクトップアプリ
XAML Islands
既存のWPF・WinForms・Win32アプリの一部分に、新しいXAML(WinUI系)のコントロールを埋め込むための仕組み。
既存WPF/WinFormsへのWinUI段階移行
既存のWPF/WinFormsアプリに、XAML IslandsなどでWinUI系のコントロールを少しずつ混ぜていく移行構想。
段階移行
標準コントロール中心の業務アプリ
標準コントロールと入力フォームが中心の、比較的小〜中規模な社内ツール・業務アプリ。
入力フォーム中心のツール
画面数の多い中〜大規模業務アプリ
画面数が多く、データバインディング・スタイル・テンプレート・MVVMを活用したい中〜大規模の業務アプリ。
Windows専用の新規モダン製品UI
Fluentや最新のWindows体験そのものが製品価値に直結する、Windows専用の新規製品のUI。
Fluent Design System
Windows 11の見た目と操作感を定めたマイクロソフトのデザイン体系。WinUIが前提にしている。
WPFはXAMLで画面を宣言的に記述するUIフレームワークである。
WinUIもXAMLを使ってUIを記述する。
WPFはデータバインディングを中心機能の1つとして持つ。
MVVMパターンのViewとViewModelは、データバインディングでつなぐ。
MVVMパターンを採用する場合、WPFはXAML・データバインディング・コマンドを通じて実践しやすい。
MVVMパターンを採用する場合、WinUIもdata binding/MVVMの導線を普通に持っている。
WinUIはWindows App SDKのUIフレームワーク部分として実装されている。
UI全面移行はせず機能だけ足したい場合、既存WPFアプリにも、App Lifecycle・Windowing・Toast NotificationsなどWindows App SDKの機能を追加できる。
UI全面移行はせず機能だけ足したい場合、既存WinFormsアプリにも、UIを維持したままWindows App SDKの機能を追加できる。
新規のWinUI 3アプリは既定でpackaged、つまりMSIXパッケージ路線が前提になる(sparse packageやunpackagedを明示的に選ばない限り)。
packaged(MSIX)モデルはpackage identityを持つ。
外部の場所を指すpackaged(sparse package)は、既存のインストーラーを保ったままpackage identityだけを付与する方式である。
unpackagedのアプリはpackage identityを持たない。
段階移行を小さく検証する場合、XAML Islandsは既存WPFアプリの一部にWinUI系のコントロールを埋め込む仕組みとして使える。
段階移行を小さく検証する場合、XAML Islandsは既存WinFormsアプリの一部にWinUI系のコントロールを埋め込む仕組みとしても使える。
既存WPF/WinFormsへのWinUI段階移行は、XAML Islandsによるコントロール埋め込みに依存する構想である。
既存WPF/WinFormsへの段階移行を、WinUI導入の主戦略として最初から前提にすることは推奨されない。先に小さく検証すべきとされる。
標準コントロール中心・入力フォーム中心の小〜中規模な社内ツールでは、WinFormsが本記事の推奨である。
画面数が多く、データバインディング・スタイル・テンプレート・MVVMを使いたい中〜大規模の業務アプリでは、WPFが本記事の推奨である。
Fluentや最新のWindows体験が製品価値に直結する新規のWindows専用製品では、WinUIが本記事の推奨である。
既存WinFormsアプリが大きい場合は、WinUIへの全面移行を検討するより先に、まずWinForms継続を基本に見るべきとされる。
既存WPFアプリが大きい場合は、WinUIへの全面移行を検討するより先に、まずWPF継続を基本に見るべきとされる。
最新のWindows機能を使いたいだけなら、WinUIへのUI全面移行より先に、既存フレームワークへのWindows App SDK部分導入を検討すべきとされる。
WinUIはFluent Design Systemを前提にしたUIフレームワークである。