Skip to content

MS_Blazor

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 3 revisions

Blazor

概要

  • 新しい SPA フレームワーク

    • WebAssemblyで動作する
    • C#、Razor、および HTML に基づく

  • C# で開発するので、

    • （特に Blazor Server において）Visual Studioによって
      ASP.NET と強く結合している。
    • 昨今、フロントとバックは様々な言語で開発される「統合」より「分離」が主流なので
      流行っていない。
    • 現時点、C# 採用時点で、その必要性は薄いか。
      そして、一応、Visual Studio の販売の目的もありそう。

補足（この評価をどう見るか）: 「流行っていない」という評価は、
フロントエンド全体の市場で見れば今も概ね妥当である
（React / Vue のシェアには遠く及ばない）。

ただし、Blazor が定着した領域はある。

向く場面 理由
社内業務システム 初回ロードの重さが許容される。C# 要員だけで完結する
既存 .NET 資産の Web 化 モデル・検証ロジックをサーバーと共有できる
管理画面 SEO 不要・利用者が限定的

逆に、一般公開の B2C サイトでは初回ロード（WASM ランタイム数 MB）が
効くため、依然として不利である。

詳細

特徴

  • Apache License, Version 2.0
  • .NET Coreの一部

開発環境

  • 前提環境

  • 開発スタイル

    • HTML ベースであり、コンポーネントベース
      • ASP.NET Web Forms、ASP.NET MVC的な方式
      • *.cshtml は原則、BlazorComponent を継承
      • カスタム・コントロールは BlazorComponent を継承して開発
    • 豊富な IntelliSense とツール
    • 開発中のブラウザでのライブリロード
    • ブラウザと IDE の両方で完全な .NET デバッグ
    • パブリッシュとアプリサイズのトリミング

移行メモ（最新化）: 「前提環境」と「BlazorComponent」は
実験段階（0.x）の記述である。正式版では次の通り。

元ページ 現在
.cshtml .razor（拡張子が変わった）
BlazorComponent を継承 ComponentBase を継承
.NET Core 2.1 以降 Blazor Server は .NET Core 3.0（2019）、Blazor WASM は .NET Core 3.2（2020）で正式版

また「ブラウザで完全な .NET デバッグ」は当初うまく動かなかったが、
現在は Chrome DevTools 経由で実用レベルになっている。

フレームワーク

  • Blazor WASM：SPA フレームワーク

    • レイアウト / ルーティング / フォーム / バリデーション
    • DI: Dependency Injection（依存性の注入）
    • JavaScript interop
    • サーバーサイドレンダリング

  • Blazor Server：ASP.NET の Update Panel の差分更新を
    SignalRで実現するようなアーキテクチャ

    • 上記の SPA フレームワーク機能は同梱される。
    • 大きな差異は、サーバーサイド実装が中心で、
      フロントエンド処理と WebAPI に依存しない点。
    • （Blazor WASM の初回アクセス時の静的サーバーサイドレンダリングが動的化されている）
    • .NET 8 以降の「Blazor Web App」では「SSR / Interactive Auto」という挙動が
      可能になった。
      （≒ 最初はサーバで描き、裏で WASM を DL し、準備ができたらクライアント側に切り替える）

補足（Blazor Server の制約）: 「Update Panel を SignalR で」という喩えは
的確だが、その帰結として次の制約がある。採用前に必ず確認したい。

制約 内容
常時接続が必要 WebSocket が切れると操作不能。モバイル回線・プロキシ環境で問題になりやすい
レイテンシが UI に直結 クリックのたびにサーバー往復。遠隔地・高遅延環境では体感が悪い
サーバーが状態を持つ ユーザー数分のサーキット（DOM 差分の状態）をメモリに保持。スケールしにくい
スケールアウト時 スティッキー セッション必須（または Azure SignalR Service）

逆に言えば、LAN 内の社内システムであればこれらはほぼ問題にならず、
「WASM のダウンロードが無く初回が速い」という利点だけが効く。

ハイブリッド化が可能

  • SPA フレームワークなので、
    PWAなどで側（皮）ネイティブ的にラップして、ハイブリッド化が可能。
  • .NET 6 から、デスクトップアプリの開発にも対応する「Blazor desktop」が加わり、
  • 以降、Blazor Hybrid や .NET 8 で Blazor United という俗称で呼ばれる
    新しい Blazor が登場
    （Blazor + Windows Formsor WPF
    or .NET MAUI）

マークアップ言語

特に、外（皮）ネイティブのハイブリッド化で複雑化した。

構成 マークアップ
Blazor WASM HTML/CSS（＋ Razor テンプレート構文）
Blazor Server 同上（実体は動的サーバーサイドレンダリングで SPA ではない）
Blazor + Windows Forms WebView 内の HTML/CSS のみ（C# のコード UI も可能）
Blazor + WPF WebView 内の HTML/CSS ＋ 外側の XAML
Blazor + .NET MAUI MAUI 自体は XAML。Blazor + で WebView 内の HTML/CSS も必要
  • Blazor 単体を見ると、SPA フレームワークと言いつつ、ほぼ、JS 代替の WASM なので、
    マークアップは HTML/CSS。
  • SPA フレームワークっぽく見せているのは、
    ASP.NET MVCから輸入された Microsoft 製のテンプレート構文の Razor。

Silverlight っポイが、

  • 同じ点

    • クロスプラットフォーム
    • ブラウザ実行 ≒ 通常実行
    • ブラウザ外実行 ≒ ハイブリッド化

  • 異なる点

    • XAMLではない。
    • プラグイン・アプローチではない。
    • 従って、Silverlightや Flash のように、
      主要ブラウザにプラグインをクローズされて使えなくなることはない。

補足（この比較は重要）: 「プラグインではない」という違いは決定的である。
Silverlight / Flash はブラウザ ベンダの許可に依存していたため、
ベンダが方針を変えた時点で終わった。

WebAssembly は W3C 標準であり、
主要ブラウザすべてが実装している。
同じ理由で消えることは、まず考えにくい。

参考

microsoft.com

Tags: 移行, .NET開発, .NET Core, ASP.NET, ASP.NET SPA, JavaScript

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally