小村軟體有限公司
日本語 English 한국어 繁體中文 العربية
聯絡我們
選單

Windows Forms、WPF、WinUI 該選哪個 - 新規開發、既有資產、發佈、UI 表現的判斷表

· · WinForms, WPF, WinUI, C#, Windows 開發, UI 設計

用 C# / .NET 製作 Windows 桌面應用程式時， 樸素地每次都很麻煩的是 WinForms、WPF、WinUI 該選哪個。

這裡危險的是，

  • 因為最新所以 WinUI
  • 因為最熟悉所以 WinForms
  • 總覺得像中間所以 WPF

這樣模糊的選法。

在實務上，該看的軸更明確一點。

  • 是新規開發還是既有資產的延長
  • 畫面是輸入表單中心還是需要表現力
  • Windows 風格的現代 UI 本身是否為產品價值
  • 發佈・更新・企業內運營怎麼做
  • 團隊是 Designer 文化還是 XAML / MVVM 文化

本文把這一帶作為判斷表以一頁容易看的形式整理。 另外，本文中所說的 WinUI 主要指 WinUI 3 + Windows App SDK。12

此外，這 3 個全部是 Windows 專用。 如果 macOS / Linux 也進入視野，本來問題設定就不同。341

1. 先講結論（一句話）

先粗略但實務上好用地講，是這樣。

  • 如果既有 WinForms 應用程式很大，先以 WinForms 繼續為基本來看
  • 如果既有 WPF 應用程式很大，先以 WPF 繼續為基本來看
  • 新規的小~中規模公司內部工具中，標準控制項中心・輸入畫面中心・想快速製作的話，WinForms 現在也相當強35
  • 新規的中~大規模業務應用程式中，畫面數多，想好好使用資料繫結、樣式、樣板、命令、MVVM 的話，WPF 最無難的情況較多467
  • 新規的 Windows 專用產品中，現代的 Windows UI、Fluent、最新的 Windows 體驗直接關係到產品價值的話，WinUI 很有力12
  • 只是想使用最新的 Windows API的話，不一定要 WinUI。WPF / WinForms 也可以納入 Windows App SDK 的功能28910
  • 以「之後慢慢插入 WinUI 就好」為前提來選，有點危險。階段遷移的話題比想像的更泥濘1011

簡言之，大概如下。

  1. 既有資產大的話，先保留那個系譜
  2. 新規快速製作標準表單的話 WinForms
  3. 新規長期成長的 Windows 業務應用程式的話 WPF
  4. 新規現代 Windows UI 本身是要件的話 WinUI
  5. 只想使用 Windows App SDK 的話，不要一口氣全部 WinUI

框架選定同時是 UI 技術的選定，也是 發佈・運營・學習成本・遷移成本的選定。 這裡只用「新 / 舊」決定的話，之後會靜靜地發揮效果。以討厭的形式。

2. 本文中所說的 3 個技術

最初先對齊一下用語。

技術 大致來說 強的軸
WinForms 用 Visual Studio 的 Designer 容易快速組表單，Windows 用的傳統 .NET 桌面 UI 快速畫面製作、標準控制項、既有資產的活用
WPF 使用 XAML、資料繫結、樣式、樣板、命令，容易做出有表現力的 UI 的 Windows 專用 UI 中~大規模業務應用程式、MVVM、畫面容易整理
WinUI Windows App SDK 上的現代 Windows 原生 UI Fluent、最新 Windows 體驗、高 DPI、現代產品 UI

WinForms 在 Microsoft Learn 也被說明為具備控制項、圖形、資料繫結、使用者輸入，容易用 Visual Studio 的拖放 Designer 製作應用程式的框架。3

WPF 是包含解析度無關的向量基礎繪圖、XAML、資料繫結、樣式 / 樣板、2D / 3D、動畫在內的表現力高的 UI 框架。4

WinUI 是 Windows App SDK 的一部分，以高 DPI、現代輸入、流暢動畫、Fluent 系列體驗為前提的現今 Windows 用 UI 框架。12 此外 data binding / MVVM 的導線也普通地具備。12

這裡重要的是 Windows App SDK 和 WinUI 不相同。 WinUI 是 Windows App SDK 的 UI 框架部分，但 Windows App SDK 本身也可以加到 WPF / WinForms / Win32 的既有應用程式。210

所以，

  • 使用 WinUI
  • 使用 Windows App SDK 的功能

看似相似但是不同的判斷。 這裡混在一起，會議室的話題會變得有點霧濛濛。

3. 一頁看的判斷表

首先放上實務上最好用的表。

狀況 先選的 理由
既有 WinForms 應用程式的改修・延命・往 .NET 的更新 WinForms 繼續 容易活用既有畫面、Designer 資產、控制項資產
既有 WPF 應用程式的改修・延命・往 .NET 的更新 WPF 繼續 容易直接活用 XAML、Binding、MVVM、畫面結構
新規、公司內部工具、設定畫面、管理畫面、輸入表單中心 WinForms 標準控制項中心的話起步快
新規、畫面數多、狀態複雜、想使用樣式 / 樣板 / MVVM WPF 容易做畫面的職責分離和 UI 的整理
新規、Windows 風格的現代 UI 本身是要件 WinUI 容易靠向 Fluent 或最新的 Windows 體驗
既有 WPF / WinForms 不動，想使用 Toast / Windowing / App Lifecycle 等 現行框架 + Windows App SDK 為了最新 Windows 功能常常不需要 UI 全面遷移
COM / ActiveX / 舊第三方控制項依賴濃 偏向既有框架 UI 之前依賴關係的遷移成本大
強受發佈・更新・企業內運營方便的影響 WPF / WinForms 優先檢討，WinUI 要早點確認發佈設計 WinUI 必須早點看 Windows App SDK / packaging 前提的論點
將來想跨平台化 包含這 3 個以外重新檢討 這 3 個全部是 Windows 專用

光這個表就相當夠用，但容易煩惱的是以下 2 點。

  1. 新規 Windows 業務應用程式，要偏向 WinForms 還是 WPF
  2. 既有 WPF / WinForms 在的情況下，應該去 WinUI 嗎

這 2 點看下面的比較表就容易整理。

4. 觀點別比較表

這裡不是官方優劣表，而是相當實務的比較。

觀點 WinForms WPF WinUI
快速製作小的輸入表單 ◎ ○ ○
標準控制項中心的公司內部工具 ◎ ○ △~○
與資料繫結 / MVVM 的相性 △ ◎ ○~◎
樣式 / 樣板 / 畫面的表現力 △ ◎ ◎
與既有 Windows 桌面資產的親和性 ◎ ○ △
現代 Windows 風格 △ ○ ◎
既有畫面的延命・階段改修 ◎ ◎ △
只想追加 Windows App SDK 功能 ○ ○ ◎
發佈 / 更新 / 運營設計的輕鬆度 ○ ○ △~○
製作「新且長期成長的 Windows 專用產品 UI」 △ ○ ◎

看法的訣竅不是什麼最強，而是什麼摩擦最少。

例如，

  • 公司內部的設定工具
  • 裝置設定畫面
  • 一覽、明細、搜尋、設定、按鈕
  • 比起外觀更重視運營的穩定和改修速度

的話，WinForms 現在也相當合理。

相反地，

  • 畫面數多
  • 顯示狀態的切換多
  • 想分離 View 和邏輯
  • 想把資料的變化自然連到 UI
  • 想用樣式 / 樣板統制 UI

的話，WPF 相當有效。67

然後，

  • 想以 Windows 11 風格的外觀為前提
  • 想好好活用 Fluent
  • 想以高 DPI、觸控、現代窗戶 API 為前提
  • 新規，作為 Windows 專用產品 UI 的印象也重要

的話，WinUI 很自然。12

5. 各自適合什麼案件

5.1 WinForms

WinForms 常被奇怪地輕視，但 在快速製作標準控制項中心的業務畫面這一點上，現在也相當強。35

特別適合的例如以下。

  • 公司內部用設定工具
  • 裝置・計測儀・監視工具的設定畫面
  • 管理畫面、搜尋畫面、一覽 + 明細
  • 既有 WinForms 資產大的案件
  • 用 Designer 組畫面的文化強的團隊

WinForms 的強處是不帶入困難的思想也能相當快速做出接近完成品的畫面。 表單、按鈕、標籤、文字方塊、資料格線。 這個世界是主戰場的話相當能戰。

但是，弱的地方也很明確。

  • 想大幅統一畫面整體的外觀
  • 想用樣式和樣板控制 UI
  • 想以資料繫結為主處理複雜的狀態變化
  • 想漂亮地分離畫面邏輯

這一帶 WPF 或 WinUI 更自然。

用 WinForms 做大應用程式，一鬆懈容易變成事件處理器的密林。 所以選 WinForms 的話，

  • 保持畫面職責小
  • 以 UserControl 單位分離
  • 意識 Presenter / ViewModel 相當的邊界
  • 不把業務邏輯緊貼著寫到畫面事件

等，從一開始決定比較和平。

還有，實務上相當重要的是不需要因為想使用 Windows App SDK 就捨棄 WinForms。 官方也有對既有 WinForms 應用程式加 Windows App SDK 功能的導線。910

也就是說，WinForms 可以

  • UI 保持不變
  • 只把必要的 Windows 功能現代化

這樣選。 這裡相當現實。

5.2 WPF

WPF 從 Windows 桌面的 .NET UI 角度看，是 平衡最好的中樞。4

強處相當明確。

  • 能用 XAML 宣告式寫畫面
  • Data Binding 強
  • 能用 Style / Template
  • 能用 Command
  • 容易分離 View 和邏輯
  • 容易整理中~大規模的畫面

WPF 的官方文件中資料繫結也被說明為 WPF 的中心功能，命令也被整理為分離輸入和執行邏輯的機制。67

所以例如相當適合以下案件。

  • 畫面數多的業務應用程式
  • 一覽、詳細、編輯、搜尋、狀態顯示多
  • 多人長期維護的 Windows 應用程式
  • 想分離 View 和邏輯
  • 將來改修時想先分離外觀和行為的職責
  • WinForms 的話畫面馬上變重

新規 Windows 專用業務應用程式迷惘時， WPF 現在也是相當安全的第一候補。 把這裡以「WPF 舊所以不行」切掉有點粗暴。

毋寧說，

  • 有既有 WPF 資產
  • 有既有 XAML / MVVM 的知識
  • 不到那麼 Fluent 最優先
  • 但想比 WinForms 更漂亮地設計 UI

的話，WPF 最有道理的情況很正常。

當然 WPF 也有癖。

  • XAML 雕琢過頭就難讀
  • 進入獨自控制項或樣板地獄的話維護重
  • 偏向「什麼都用 Binding」宗教反而難追

這一帶有。 只是，那不是 WPF 不好，而是有表現力的工具粗暴揮動反彈也大的話題。

WPF 也可以追加 Windows App SDK 的一部分功能。 也就是說，有保持 WPF 現代化 Windows 功能的路。810

因此，

  • 全部捨棄 WPF 全面遷移到 WinUI

比起，

  • 把 WPF 靠向現行 .NET
  • 只把必要的 Windows 功能用 Windows App SDK 補
  • 從新規的大功能整理構成

在實務上常常比較容易贏。

5.3 WinUI

WinUI 是製作新規 Windows 專用應用程式時的現代本命。12

官方定位是，

  • 為最新硬體和輸入最佳化
  • 高 DPI
  • 流暢動畫
  • Windows App SDK 的一部分

這樣。1

所以適合這樣的案件。

  • Windows 專用的新規產品
  • UI 的印象或體驗本身重要
  • 想自然使用 Fluent
  • 想靠向 Windows 11 的現在位置
  • 想以新的窗戶 API 或最新 Windows 體驗為前提

有好好選 WinUI 理由的案件， 大概是「不是外觀新，而是想把 Windows 的現在體驗納入產品」的案件。

另一方面也有注意點。

5.3.1 WinUI 不是「只是新的 WPF」

因為用 XAML 看起來相近，但

  • 基礎的 API
  • 控制項周邊
  • 專案構成
  • 部署 / packaging 的思考方式
  • 與 Windows App SDK 的相處方式

不同。

也就是說，想成從 WPF 輕鬆的替換目標有點危險。

5.3.2 選 WinUI，發佈的話題會跑到前面

WinUI 3 應用程式以 packaged 為預設。 另一方面 Windows App SDK 本身處理 packaged / unpackaged 兩方。13142

這裡重要的是，

  • 要怎麼發佈
  • 怎麼放入執行環境
  • 是否需要 package identity
  • 是公司內部發佈、Store、MSIX，還是既有 EXE / MSI 路線

早點決定比較好。

WinForms / WPF 發佈也重要，但 WinUI 這裡容易跑到前景。 以為決定了 UI，實際上是在決定發佈策略，是這個世界稍微麻煩的地方。

5.3.3 「在既有 WPF / WinForms 慢慢混入 WinUI」先實驗

這裡是期待容易膨脹的地方。 但是，Microsoft 的 FAQ 也寫著除非準備好完全遷移 UI 框架，否則常常不能用 WinUI 的意思。 進一步 XAML Islands 周邊官方文件雖然提示了往既有桌面應用程式嵌入的導線，但 Windows App SDK 1.4 的發布記錄中寫著現階段主要在 C++ 應用程式上測試，還沒放入 WPF / WinForms 用的便利封裝元素。1011

也就是說，

  • 「階段遷移好像可行」
  • 「慢慢填充好像可以」

作為構想有魅力，但在作為案件的主策略前最好小規模驗證。

WinUI，

  • 新規開始
  • 作為 Windows 專用產品製作體驗

時最有道理。 相反地，作為既有 WPF / WinForms 全面替換的接盤需要理由和驗證。

6. 常見的判斷錯誤

6.1 「因為最新所以 WinUI」

這個很易懂，但相當危險。

選新技術的理由，最好用 是否有那個技術才能得到的價值來看。

  • 現代 Windows 體驗是否為產品價值
  • 想自然使用 Fluent 嗎
  • 是新規產品嗎
  • 能接受發佈 / 運營的前提嗎

這裡是 yes 的話 WinUI 相當有力。 相反地，單純「好像有將來性」成本的說明弱。

6.2 「想使用 Windows App SDK 所以必須用 WinUI」

這個容易被誤解，但不是。

Windows App SDK 也可以加到既有的 WPF / WinForms。 官方 FAQ 也整理出 WPF / MFC / WinForms 應用程式可以使用與 WinUI 無關的 Windows App SDK API。1089

例如，

  • App Lifecycle
  • Windowing
  • Toast Notifications

這樣的功能有時可以在保持現在的 UI 下納入。10

6.3 「WPF / WinForms 已經結束了」

這裡也最好不要粗暴切。

WinForms 和 WPF 都在現行 .NET 上文件和遷移導線繼續著，官方也作為現役的 Windows 桌面 UI 對待。34

特別在業務應用程式中，

  • 既有資產
  • 第三方控制項
  • 畫面數
  • 報表或列印
  • 裝置連動
  • 發佈步驟

比起 UI 框架的新舊更重的情況很正常。

6.4 「反正要全面重寫」

全面重寫不是技術選定，接近事業判斷。

有既有應用程式的話，最先該看的是以下。

  1. 真正困擾的是什麼
  2. 是 UI 的問題還是架構的問題
  3. 依賴 DLL / COM / OCX / 報表 / 發佈不是真正的重擔嗎
  4. 不全部改 UI 就解決不了困擾嗎

UI 重寫華麗，但成本也華麗。 而且，就算外觀變新，周邊的麻煩通常還留著。

6.5 「之後用 XAML Islands 會有辦法」

這個期待能理解。 但是，從一開始不要當作救生艇比較安全。1011

階段遷移，

  • 想嵌入的控制項是什麼
  • 焦點、輸入、DPI、主題會怎樣
  • 實際上那個主機構成是否穩定

先小規模試比較好。

7. 以既有應用程式為前提時的看法

這裡比起新規，既有更重要。

7.1 有既有 WinForms 的話

首先，突然跳到 WinUI 前，看以下。

  • 能否靠向現行 .NET
  • 是否需要 64bit 化
  • 能否整理 async / await、例外處理、設定、日誌
  • 能否用畫面分割或 UserControl 化提高維護性
  • 能否只用 Windows App SDK 補必要的 Windows 功能

看似 WinForms 的問題，實際上是

  • 畫面和邏輯混在一起
  • 執行緒邊界粗糙
  • 設定 / 檔案 / COM / DB 的職責擠著

而已的情況很多。

那樣的情況，就算搬到 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
  • 32bit / 64bit 的扭曲
  • 安裝程式、權限、更新、簽章

輕視這裡的話，只把 UI 弄漂亮案件整體不會變輕。

所以既有應用程式的遷移中， 不只看 UI 框架，連依賴邊界一併盤點比較先。

8. 迷惘時最後看的 5 問

最終迷惘的話，依序看以下 5 問。

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 要早點打磨 packaging / deployment
  • 想強烈搭到既有運營上 → WPF / WinForms 摩擦少的情況較多

這 5 問就能相當縮小。 最後粗略地整理，是這樣的感覺。

  • 快速製作的公司內部表單 → WinForms
  • 長期成長的 Windows 業務應用程式 → WPF
  • 新規的現代 Windows 產品 UI → WinUI
  • 活用既有只現代化 Windows 功能 → 現行框架 + Windows App SDK

9. 總結

WinForms、WPF、WinUI 的選定， 不是按新舊順序排列取最右邊的遊戲。

先該看的是以下 4 個。

  1. 既有資產在哪
  2. 畫面是表單中心還是表現力中心
  3. Windows 風格的現代 UI 是否為產品要件
  4. 發佈 / 更新 / 運營怎麼跑

看見這 4 個，大致可以整理如下。

  • 如果有大量既有 WinForms，先 WinForms 繼續
  • 如果有大量既有 WPF，先 WPF 繼續
  • 新規標準表單中心的話 WinForms
  • 新規中~大規模的 Windows 業務應用程式的話 WPF
  • 新規現代 Windows 體驗本身是要件的話 WinUI
  • 只想使用 Windows App SDK 的話，不要一口氣全部 WinUI

最想避免的是，

  • 因為舊所以捨棄
  • 因為新所以選
  • 以中途會有辦法開始

這 3 個。

Windows 桌面是比起外觀資產、發佈、運營、依賴關係更重的世界。 所以選法也比起閃亮感看摩擦的少通常比較容易贏。

10. 參考資料

  1. Microsoft Learn, “WinUI 3 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/winui/winui3/ / Microsoft Learn, “Modernize your desktop apps for Windows” https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Microsoft Learn, “Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  3. Microsoft Learn, “Windows Forms 是什麼 - Windows Forms” https://learn.microsoft.com/en-us/dotnet/desktop/winforms/overview/ ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn, “Windows Presentation Foundation 是什麼 - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/overview/ ↩ ↩2 ↩3 ↩4 ↩5

  5. Microsoft Learn, “What is Windows Forms Designer?” https://learn.microsoft.com/en-us/visualstudio/designers/windows-forms-designer-overview?view=visualstudio ↩ ↩2

  6. Microsoft Learn, “Data binding overview - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/data/ ↩ ↩2 ↩3

  7. Microsoft Learn, “Commanding Overview - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/commanding-overview ↩ ↩2 ↩3

  8. Microsoft Learn, “在 WPF 應用程式中使用 Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/wpf-plus-winappsdk ↩ ↩2 ↩3

  9. Microsoft Learn, “Use the Windows App SDK in a Windows Forms (WinForms) app” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/winforms-plus-winappsdk ↩ ↩2 ↩3

  10. Microsoft Learn, “Windows 開發者 FAQ” https://learn.microsoft.com/en-us/windows/apps/get-started/windows-developer-faq ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  11. Microsoft Learn, “Windows App SDK 1.4 release notes” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/release-notes/windows-app-sdk-1-4 / Microsoft Learn, “Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/ ↩ ↩2 ↩3

  12. Microsoft Learn, “Windows data binding and MVVM” https://learn.microsoft.com/en-us/windows/apps/develop/data-binding/data-binding-and-mvvm ↩

  13. Microsoft Learn, “Packaging overview - Windows apps” https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/packaging/ ↩

  14. Microsoft Learn, “Quick start: Set up your environment and create a WinUI 3 project” https://learn.microsoft.com/en-gb/windows/apps/get-started/start-here ↩

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽