Blazor入門：ASP.NET Coreで始める最新Web開発

これは豆蔵デベロッパーサイトアドベントカレンダー2024第20日目の記事です。

そう言えば「最近の.NETってどうなっているのかなぁ？」と気になりだしたので、最新のLTS版である.NET 8.0に関した記事を書きたいと思います。

ここ数年の開発プロジェクトではJavaを利用する機会が多く、筆者が.NETに触れるのは約10年ぶりとなります。
この10年の間で.NETも大きな進化を遂げ、Windowsに限定された.NETは、.NET Core^[1]のリリースによってクロスプラットフォームにも対応されました。

その中でも今回は、10年前には存在しなかったASP.NET Core Blazor（以下、Blazor）というものについて取り上げたいと思います。

まず、Blazorとは何かについて説明させていただきます。

簡単に言ってしまえば、C#でWeb UIを開発するためのフレームワークです。
Blazorでは、JavaScriptやTypeScriptの代わりに、C#と.NETを使ってリッチかつインタラクティブなWeb UIを構築することが可能となります。

このように、Blazorの登場によってフロントエンドからバックエンドまでをひとつのプログラミング言語、つまりC#のみで開発できるのは開発者にとって大きなメリットと言えるでしょう。

Blazorには、「Blazor WebAssembly」と「Blazor Server」の2つの実行モデルがあります。
Blazorの特徴としては、ほぼ同じコードでこの2つの異なるモデルを動作させることができます。

2つの実行モデルのイメージを示したものが次の図となります。

Blazor WebAssemblyは、クライアント中心の実行モデルとなります。WebAssemblyという標準技術に基づいてBlazorアプリケーションがブラウザ上で動作します。
Blazorアプリケーションと、依存関係のあるライブラリをブラウザにダウンロードするため、初期起動には若干のオーバーヘッドが発生します。ですが、一度起動してしまえば、ネットワークとの常時接続を必要としません。

一方、Blazor Serverはその名のとおり、サーバー中心の実行モデルとなります。文書ツリー（DOM）だけがブラウザに返却され、UI上の操作に応じてサーバーサイドへ処理を要求します。
「SignalR」と呼ばれるリアルタイム通信のライブラリによって、クライアントとサーバー間の変更は互いに即時反映することが可能となります。この性質上、初期起動は高速な反面、ネットワークとの常時接続は必要となります。

Blazor Unitedとは、.NET 8.0から導入された機能で、ページや一部のコンポーネントごとに4つのレンダリングモードを切り替えることが可能となりました。
Blazor Unitedにおける4つのレンダリングモードは次のとおりです。

1. 静的 Server Side Rendering（Static SSR）
2. 対話型サーバー（Interactive Server）
3. 対話型WebAssembly（Interactive WebAssembly）
4. 対話型オート（Interactive Auto）

これまで、BlazorでWebアプリケーションを開発する際には、先述の2つの実行モデルのうち、アプリケーションの単位でどちらか一方を選択する必要がありました。
これがBlazor Unitedの導入によって、ひとつのアプリケーションで複数のレンダリングモードを使い分けることができるようになりました。

それでは、Blazor Unitedにおけるそれぞれのレンダリングモードについて見ていくことにしましょう。

Static SSRは、Blazorが登場する前のASP.NET MVCのRazorページに近いレンダリングモードとなります。
サーバーサイドで一度だけレンダリング処理が行われて、それがクライアントに返却されるというものです。
ページの表示後に対話的な操作が不要なページで利用することができます。

従来のBlazor Serverとほぼ同じ実行モデルで、Razorページのコードブロック（C#のコード部分）がサーバーサイドで実行されます。
クライアントとサーバー間はSignalR回線によって連携され、描画はクライアントサイドのブラウザ側で行われます。

.NET 8.0からはBlazor Unitedによって、SignalRの回線をページやコンポーネントの単位に指定することができます。
以前は、ブラウザの起動から終了までの同一セッションにおいて、SignalR回線を張り続けていました。これが.NET 8.0で改善され、ページが切り替わるタイミングでSignalR回線と、それに関連するサーバーリソースが解放されるようになりました。

従来のBlazor Assemblyとほぼ同じ実行モデルで、WebAssemblyを使ってブラウザ内で処理が行われます。
アプリケーション全体でこのモードしか利用しないケースでは、サーバーサイドの処理が完全に不要になるため、静的なWebサーバー上にBlazorアプリケーションを配置することもできます。

Blazor WebAssemblyでは、初回の起動が遅いという問題がありましたが、これを解決するのがInteractive Autoとなります。

初回のページが呼び出された際はInteractive Serverモードで動作しながら、バックグラウンドでWebAssemblyモジュールがダウンロードされます。
ブラウザ側にすべてのWebAssemblyモジュールがキャッシュされると、その後はブラウザ内で動作します。

Blazor Unitedが導入されたことで、従来のBlazor WebAssemblyやBlazor Serverでアプリケーションを開発することはなくなったかと言うと、そんなことはありません。
.NET 8.0においても、従来の開発モデルを選択することは可能ですし、開発プロジェクトやシステムの特性に応じて最適な開発モデルを選択するのが良いと考えます。

ここでは、Visual Studioを用いて、各Blazorアプリケーションの開発の進め方についてご紹介したいと思います。

誠に勝手ながら今回は、Visual Studioのプロジェクトテンプレートによる、Blazorアプリケーションの開発準備までとさせていただきます。
このため、プロジェクト構成や個々の要素につきましては、改めましてまたの機会に説明させていただきます。

Visual Studioを用いて、従来のBlazor WebAssembly型のアプリケーションを開発するには、プロジェクトテンプレートに「Blazor WebAssembly アプリ」を選択します。

追加情報は次のとおり、デフォルトのままで構いません。
「Include sample pages」を選択することで、プロジェクトの作成時にサンプルアプリケーションが追加されます。

Blazor WebAssembly型のプロジェクト構成は、次のようになります。
なお、先述のとおり、プロジェクト内の個々の要素につきましては、またの機会に説明させていただきます。

何も手を加えずにそのままを実行すると、次のようなWebアプリケーションが起動します。

従来のBlazor Server型のアプリケーションを開発するには、プロジェクトテンプレートに「Blazor Web App」を選択します。

この他に、「Blazor Server アプリ」というプロジェクトテンプレートがありますが、こちらは.NET 8.0ではサポートされていませんのでご注意ください。

追加情報では、次の2つを選択してください。これにより、サーバーサイドのレンダリングモードのみのBlazorアプリケーションを開発することができます。

• Interactive render mode : Server
• Interactivity location : Global

Blazor Server型のプロジェクト構成は、次のようになります。

Blazor WebAssembly型と比較すると、サーバー固有のRoutes.razor、appsettings.jsonと、エラーページのError.razorが追加されました。

なお、起動するWebアプリケーションはBlazor WebAssembly型と同様であるため、割愛させていただきます。

.NET 8.0で導入されたBlazor United型のアプリケーションを開発するには、プロジェクトテンプレートに「Blazor Web App」を選択します。

追加情報では、次の2つを選択してください。これにより、4種類のレンダリングモードを組み合わせたBlazorアプリケーションを開発することができます。

• Interactive render mode : Auto(Server and WebAssembly)
• Interactivity location : Per page/component

Blazor United型のプロジェクト構成は、次のようになります。

Blazor WebAssembly型やBlazor Server型のプロジェクト構成と比べると、2つのプロジェクトが作成されているのがわかると思います。

なお、起動するWebアプリケーションは他と同様であるため、割愛させていただきます。

今回は、ASP.NET Core Blazorの概要について書かせていただきました。

.NET 8.0でBlazor Unitedが導入され、フルスタックなWeb UIフレームワークに進化したと言われています。
今はまだ少ないですが、近い将来、Webアプリケーションを開発するうえでの選択肢にBlazorが含まれることを願いたいと思います。

その一方で、Blazor Unitedの導入によって幾分、複雑化した印象も受けました。
以前は、筆者のようなエンジニアでも.NETであれば迷うことなく開発できたと記憶していましたが、現在のBlazorにおいては一定の設計方針やガイドラインなどの必要性を感じました。
このあたりの選定基準や考え方につきましては、次回以降の投稿で明らかにしていきたいと思います。

それでは、最後までご覧いただきありがとうございました。次回を楽しみにお待ちいただけると幸いでございます。