- Blazor時代のUI設計：WPF設計者がどう乗り換えるか？
- WPFとの違いを理解しつつ、BlazorのUI設計を攻略する
- Blazorでの状態管理とWPF設計の違いを乗り越える具体策
- WPFからBlazorへの段階的移行とチームでの設計統一戦略
Blazor時代のUI設計：WPF設計者がどう乗り換えるか？
「WPFでの経験、どう活かせるんだろう？」と感じた瞬間
WPFを長年使ってきたあなたなら、こんな思いを抱いたことがあるかもしれない。
「Webも捨てがたいけど、UI設計はやっぱりWPFの方が自由で作りやすいよな…」
「でも最近は、会社でもBlazorとかReactの話が増えてきてるし…」
僕もまさにそんな気持ちからBlazorに飛び込んだ一人だ。
正直に言うと、最初は戸惑いも多かった。
Blazorって何？ざっくりまとめると…
- Microsoftが提供する最新のWeb UIフレームワーク
- C#で書けて、Webブラウザ上で動く（JavaScript不要）
- Server-SideとWebAssemblyの2種類のホスティング方式がある
- Razorコンポーネントという単位でUIを構成する
…WPFのXAMLとは違うけど、
「C#で書けるUI」という点は共通しているのが心強い。
でも、UI設計の本質は“変わらない”
たとえUI技術が変わっても、
- 「ユーザー操作と画面の状態をどう整理するか」
- 「コンポーネント（部品）の責任をどう切り分けるか」
- 「再利用性・保守性をどう担保するか」
といったUI設計の根本的な課題は変わらない。
これは、WPFで経験した「MVVMの設計力」や「ResourceDictionaryでのテーマ管理」の経験が、
Blazorでもそのまま生かせるということだ。
乗り換えのハードルはある。でも、それを超えた先にあるメリットも大きい
- Webアプリとしてデプロイが楽になる
- モバイルも含めたクロスプラットフォーム展開が可能に
- Microsoft製品との親和性が強く、Azureとの連携もスムーズ
こうした未来志向のメリットを享受しつつ、
WPFで培った設計力を武器に新技術に挑戦できるのは大きな強みだ。
このシリーズで扱うこと
このVol.6では、以下のポイントに沿って、
- WPF設計者がBlazor UI設計で押さえるべき共通点と違い
- コンポーネント設計の考え方と、状態管理のポイント
- 実務でBlazorに移行する際の落とし穴と回避策
を、現場目線でじっくり解説していく。
なぜ今Blazorに注目すべきか？
Blazorはまだ「Web界隈の主流」とは言えないかもしれないが、
Microsoftが強力に推している技術であり、
- C#と.NETの資産をWebへ持ち込める
- 新規プロジェクトだけでなく、既存WPF資産との連携も進んでいる
という点で、**WPF設計者のキャリアにとって重要な“次のステップ”**となる。
まとめ：変わる技術、変わらない設計力
WPFからBlazorへの移行は、
コードの書き方やUI表現は変わるが、
「設計の本質＝ユーザー体験をどう設計し、どう実装するか」
は不変であり、むしろ設計力を強化するチャンスでもある。
WPFとの違いを理解しつつ、BlazorのUI設計を攻略する
1. BlazorのUI構成：Razorコンポーネントの世界
Blazorでは、UIは「Razorコンポーネント」と呼ばれる単位で構成される。
これはWPFの「UserControl」や「CustomControl」に近い考え方だが、いくつか違いがある。
1-1. Razorコンポーネントとは？
.razorファイルとして実装され、HTMLとC#が混ざった記法で記述する- UIのレイアウト（HTML） と ロジック（C#） を一つのファイルで管理する
- ネスト可能で再利用可能なUIパーツとして機能する
1-2. WPFとの比較ポイント
| 項目 | WPF | Blazor |
|---|---|---|
| UI定義 | XAML（宣言的UI） | Razor（HTML＋C#混在） |
| UIとコードの分離 | XAML + CodeBehind/ViewModel | 一つの.razorファイルに両方記述 |
| コンポーネント単位 | UserControl、CustomControl | Razorコンポーネント |
| データバインディング | 双方向バインディング（TwoWay） | 双方向バインディング可能（bind） |
| スタイル | ResourceDictionary | CSS、Scoped CSS |
2. MVVMに近いけど違う？Blazorの状態管理
WPFはMVVMパターンが鉄板で、
ViewModelに状態とロジックを分離するのが定石だ。
一方、Blazorはコンポーネント単位で状態を持ち、
状態の管理・更新はコンポーネント内で完結することが多い。
2-1. 状態管理の考え方の違い
- WPF
- ViewModelは独立したクラスとして存在し、ViewはBindingだけする
- コマンドやプロパティ変更通知で双方向連携
- Blazor
- コンポーネントがUIとロジックを併せ持ち、状態はプライベートフィールドやプロパティで管理
@bindディレクティブで双方向バインディング- 状態変更時は
StateHasChanged()でUIを更新
2-2. MVVM的設計は可能？
もちろん、BlazorでもMVVM風の設計は可能だが、
必須ではないのが大きな違い。
- 状態をViewModelクラスに分離し、DI（依存注入）で渡すこともできる
- ただしコンポーネント自体がViewとViewModelの役割を兼ねることが多い
3. Razorコンポーネント設計のポイント
BlazorでのUI設計は「コンポーネント設計」が命。
3-1. コンポーネントの責任範囲を明確に
- 1コンポーネント＝1機能単位で設計
- 親子関係で状態やイベントを受け渡す
- State管理は可能な限り局所化
3-2. データの受け渡しはパラメーター経由
- 親→子へは
@Parameter属性を使ってデータを渡す - 子→親へは、
EventCallbackを使い、イベントを通知
3-3. スタイル管理はCSS主体
- WPFのResourceDictionaryとは違い、CSSやScoped CSSで見た目を管理
- BlazorではCSS分離が原則なので、設計上はUIロジックとCSSを分けて管理する意識が必要
4. WPF設計者が意識すべきBlazorの“落とし穴”
4-1. UIとロジックの分離度が低い？
- WPFに慣れた設計者は「UIとロジックは分離すべき」という意識が強い
- Blazorではコンポーネント内にUIとロジックが混在しがちで、慣れないとコードが肥大化することも
4-2. 状態管理のスコープが狭いことに注意
- 状態管理はコンポーネント単位が基本
- 複数コンポーネントで状態を共有する場合は
StateContainerやFluxパターンなどの導入が必要になる - これはWPFのViewModel共有とは違う考え方
4-3. CSSによるスタイル管理の慣れ
- WPFのテーマやリソース辞書管理に慣れていると、CSS設計に戸惑う
- BlazorではCSSのグローバル影響やスコープを理解し、CSS設計のベストプラクティスを学ぶ必要がある
まとめ：WPF設計者は「設計力」を武器にBlazorを攻略できる
- WPFで培った「責任分割」「再利用性」「状態管理」の設計思考はBlazorに活きる
- コード構成やUI定義の書き方は違うが、設計の本質は同じ
- Blazor独特のポイント（コンポーネントの状態管理、CSS設計）に慣れれば、WebでもUI設計の力を発揮できる
Blazorでの状態管理とWPF設計の違いを乗り越える具体策
1. Blazorにおける状態管理の全体像
Blazorアプリは、UIの状態をいかに管理するかが設計のキモ。
WPFのMVVMのViewModelとは異なり、Blazorでは状態管理に複数のパターンが存在し、使い分けが必要だ。
1-1. コンポーネント内部状態
- 最もシンプルな状態管理方法
- コンポーネント内部のprivateフィールドやプロパティで状態を持つ
- 状態更新時は
StateHasChanged()を呼んでUIを再描画 - 小規模な機能や画面単位の状態管理に適している
1-2. Cascading Parameters（カスケーディングパラメーター）
- 親から深い子孫コンポーネントまで状態やサービスを渡せる仕組み
- グローバルに近い状態や、テーマ情報などの共有に使われる
1-3. DI（依存注入）でサービスとして状態を共有
- シングルトンやScopedライフサイクルの状態管理サービスを作成
- 画面間や複数コンポーネントで状態を共有できる
- ReduxやFlux風の状態管理を自作可能
1-4. 外部ライブラリの状態管理パターン
- Fluxor、Blazor-State、Redux.NETなどの導入で大規模状態を管理
- 大規模アプリに適し、状態の一元管理や履歴管理ができる
2. WPFのViewModelとBlazorの状態管理の違い
| ポイント | WPF MVVM | Blazor状態管理 |
|---|---|---|
| 状態の保管場所 | 独立したViewModelクラス | コンポーネント内or状態管理サービス |
| UI更新通知 | INotifyPropertyChanged | StateHasChanged() |
| 状態共有 | ViewModelを複数Viewで共有 | DIサービスやCascading Parameterで共有 |
| コマンド実装 | ICommandインターフェイス使用 | メソッドを直接イベントハンドラに紐付け |
| イベントの伝播 | DelegateCommandなどを利用 | EventCallbackで親子間イベント通知 |
3. 具体的な設計例：画面間で共有する「カート機能」の設計
3-1. WPFでの設計例
- CartViewModelを用意し、商品追加・削除のロジックを実装
- 複数Viewが同じCartViewModelインスタンスを参照
- プロパティ変更通知でUI更新をトリガー
3-2. Blazorでの設計例
CartStateServiceというサービスクラスを作成し、DIでコンポーネントに注入- 商品追加・削除メソッドと状態保持用プロパティを実装
- 状態変更時は
NotifyStateChangedのようなイベントを発行し、登録コンポーネントが再描画
public class CartStateService
{
public event Action OnChange;
private List<Product> cartItems = new List<Product>();
public IReadOnlyList<Product> CartItems => cartItems;
public void AddItem(Product item)
{
cartItems.Add(item);
NotifyStateChanged();
}
public void RemoveItem(Product item)
{
cartItems.Remove(item);
NotifyStateChanged();
}
private void NotifyStateChanged() => OnChange?.Invoke();
}
- コンポーネント側で
OnChangeイベントを購読し、状態変更時にStateHasChanged()を呼ぶ
4. イベントとコマンドの違いを理解する
4-1. WPFのコマンドとは？
- ICommandを実装し、CanExecuteとExecuteメソッドでUIイベントを制御
- ボタンの有効/無効状態とロジックを一元管理
4-2. Blazorのイベント処理
- メソッドを直接UI要素にバインド（
@onclick="OnClickHandler"） - コマンドの概念はないが、ロジックで有効/無効を制御し、ボタンのdisabled属性を制御する
5. 複数コンポーネント間の状態共有のポイント
- 状態共有はサービスとして切り出し、DIで注入するのが基本
EventCallbackやActionを使い親子間でイベント通知- 深い階層にはCascading Parameterで状態を渡す
- 状態管理ライブラリ導入も検討
6. WPF設計者が意識したいBlazor設計のコツ
✅ コンポーネントを小さく、単機能にする
- WPFでUserControlを分割する感覚を活かす
- Razorコンポーネントも粒度を細かくし、責務分離を徹底
✅ 状態はできるだけ局所管理、必要なら共有サービスへ
- 状態をむやみに大きくせず、UIの局所で完結させる
- 複数コンポーネントで必要な状態はサービスに切り出す
✅ CSS管理は早めに習熟する
- スタイル管理はWPFとは違うので、CSSの基本とScoped CSSを学ぶ
- 見た目の再利用はCSS設計から考える
まとめ
- Blazorの状態管理は多様だが、WPFのMVVM経験は大きな武器になる
- ViewModelと状態管理サービスの役割の違いを理解することが重要
- イベント処理やUIの分割方法はWPF設計者のスキルが活きる
- CSS設計に早めに慣れることもポイント
WPFからBlazorへの段階的移行とチームでの設計統一戦略
1. 実務でよくある課題：WPF資産をどう活かすか？
企業の既存システムは多くがWPFベースで、
「完全にBlazorに一気に切り替えるのは難しい」
という現場がほとんど。
そこで重要なのは、
- WPF資産を最大限活かしつつ
- 新規・将来機能をBlazorで開発する
という段階的な移行戦略だ。
2. 段階的移行のパターン例
2-1. 並行運用パターン
- WPFとBlazorのアプリを別々に並行開発・運用
- 新機能はBlazorで、既存機能はWPFのまま
- 最終的にBlazorに機能移管を進める
2-2. 部分的Web化パターン
- WPF内にWebView（Chromium Embedded Frameworkなど）を埋め込み
- 一部画面・モジュールをBlazorで作成し、WebView経由で呼び出す
- 段階的にWeb化を進める
2-3. API分離・UI差し替えパターン
- ビジネスロジックは.NET Core Web APIとして共通化
- UIはWPFとBlazorで別々に開発
- 将来的にBlazorにUIを統一
3. 移行時の設計ルール統一のコツ
3-1. 状態管理の統一基準を作る
- 両技術で状態の持ち方を比較・整理
- 共有サービス設計やデータフローの基準をチームで定める
3-2. コンポーネント設計の共通言語を持つ
- WPFのUserControlとBlazorコンポーネントの役割を対応付ける
- 命名規則、責務範囲を明文化し共有
3-3. デザイン・テーマの整合性
- カラー、フォント、アイコンなどのテーマ情報は共通化
- CSSとResourceDictionaryの差異を橋渡しするルール作成
3-4. ドキュメントとコードレビューで設計意図を共有
- 設計書・仕様書にWPF→Blazorでの考慮ポイントを明示
- チーム全員が理解できるようレビュー基準を設ける
4. チーム全体で「UI設計力」を高める仕組みづくり
✅ 定期的な技術勉強会を開催
- WPFとBlazorの設計・実装の違いをチームで学ぶ場を作る
- 実例コードやトラブル事例を共有
✅ ペアプログラミングやコードレビューでナレッジ共有
- 移行期は意識のズレが起きやすい
- ペアでレビューしながら設計意図を伝える
✅ UI設計に関するガイドラインの整備
- 設計思想、パターン、スタイルのルールブックを作成
- 新人・外部メンバーもスムーズに参加可能に
5. 移行で意識したい“設計の本質”を再確認
- UIはユーザー体験を作るための「手段」
- 技術は変わっても、ユーザーの期待・操作フローは変わらない
- 設計はユーザー視点を起点にすることが最重要
- WPFで磨いた設計力を軸に、Blazorでもユーザー体験の質を高め続ける
6. まとめ：未来を見据えたUI設計者としての進化
- WPF設計者はBlazorに乗り換えることで、Web／クロスプラットフォームのUI設計者へとキャリアアップできる
- 移行は段階的に、設計ルール・チーム文化を整備しながら進めるのが成功の鍵
- 技術に振り回されず、設計の本質を押さえ続けることが最大の武器になる
コメント