Microsoft は、ASP.NET Core プラットフォームに新たに追加された Blazor フレームワークを、2002 年の .NET Framework の最初のリリースにまで遡るプログラミング モデルである Web フォームにまだ固執している C# 開発者に適したアップグレードとして売り込んでいます。
クリックして拡大
Webフォームは、デスクトップ開発者がWebアプリケーションへの移行を容易にするために設計されました。ビジュアルデザイナー、ボタンやリストボックスなどのコントロールを備えたツールボックスが用意されており、開発者はコントロールをダブルクリックして、サーバー上で実行されるC#コードを記述できます。
ウェブのステートレスモデルは、ポストバックシステムと、コントロールの状態を記録する隠されたViewState変数によって隠されています。一見すると使いやすさはMicrosoftプラットフォームの開発者に広く採用されましたが、このフレームワークには不満点もあります。ユニットテストとの統合が難しく、ViewState駆動型の抽象化が期待通りに動作しない場合に問題やバグが発生しやすく、最新のJavaScriptライブラリとの整合性も欠けています。
ASP.NET Web フォームはまだ古いにもかかわらず、Microsoft は昨年、「毎月約 50 万人の Web 開発者が ASP.NET Web フォームを使用している」と述べています。
これはある意味奇妙な話です。というのも、MicrosoftがWebフォームの問題を解決することを目的としたWebフレームワーク、ASP.NET MVC（2009年）をリリースしてから10年以上が経過しているからです。ASP.NET MVC（MVCはModel View Controllerの略）には、ルーティングとビジネスロジックを処理するコントローラーファイルと、Webページをレンダリングするビューエンジンが含まれています。
モデルアスペクトはデータベースを抽象化し、多くの場合MicrosoftのEntity Frameworkオブジェクトリレーショナルマッピングを使用します。ASP.NET MVCはよりクリーンなアプローチを採用しており、ユニットテストに適しています。オリジナルのビューエンジンはポストバックシステムのないWebフォームを使用していましたが、すぐにRazorと呼ばれる構文を使用してHTMLとJavaScriptに動的コンテンツを埋め込む新しいエンジンに置き換えられました。
Razor は存続していますが、ASP.NET MVC は Razor Pages に取って代わられました。Razor Pages は類似していますが、より論理的な設計になっています (また、「MVC」の側面が純粋ではなかったことも認識しています)。ASP.NET MVC または Razor Pages が現在では主流の選択肢となっていますが、なぜこれほど多くの人が Web フォームに固執しているのでしょうか。おそらくその答えは、学習が容易で、開発者がすべてのコードを C# または Visual Basic で記述できるためです。目標がビジネス上の問題のソリューションである場合、多くの場合これで十分です。Microsoft のデスクトップ フレームワークと類似点があります。Windows Presentation Framework は、古い Windows フォームの多くの問題 (スケーリング、グラフィック アクセラレーション、リッチ デザイン) を修正しましたが、複雑さが増したため、多くの開発者が移行を拒否しました。
MicrosoftはWebフォームのサポートを継続していますが、この技術は現在凍結されており、ASP.NET Coreへの移植は行われていません。主にWindowsのみで動作しますが、クロスプラットフォームのMonoは一部サポートしています。
Blazorの登場
そこで登場するのが、MicrosoftのASP.NETチームが生み出した最新のWebアプリケーションフレームワーク、Blazorです。Blazorは2018年初頭に登場しました。Microsoftは、これがWindows Formsに未だに固執しているユーザーを惹きつけるきっかけになると考えているようで、移行方法に関する電子書籍を提供しています。ただし、「ASP.NET Web FormsからBlazorへのコードベースの移行は時間のかかる作業です」とも述べています。
Blazorアプリケーションのコードは標準の.NETアセンブリで記述されていますが、ユーザーインターフェースは標準のHTMLとCSSです。
BlazorはWebフォームとはあまり似ていませんが、いくつか共通点があります。一つは、開発者がサーバー側でもブラウザクライアント側でも、どこでもC#を記述できることです。Microsoftはこれを「フルスタックC#」と呼んでいます。
「Blazorは、再利用可能なコンポーネントモデルやユーザーイベントのシンプルな処理方法など、ASP.NET Webフォームと多くの共通点を持っています」と著者らは述べています。Blazorフレームワークにはいくつかの形態があります。最初のコンセプトであり、選択肢の一つであるのがBlazor WebAssembly（Wasm）です。.NETランタイムはWasmにコンパイルされ、アプリケーションは.NET DLLにコンパイルされ、JavaScript相互運用機能によって補完されながらブラウザで実行されます。
Blazor WebAssembly をちょっと覗いてみるのは簡単です。SDK（例えば来週リリース予定の注目の最新 .NET 5.0 など）をインストールし、次のコマンドを入力します。
dotnet new blazorwasm -o BlazorHello
次に次のように入力します:
dotnet ウォッチ実行
サンプルアプリケーションを実行します。リリースビルドを確認すると分かりやすいでしょう。他のアセンブリと同様に、BlazorHello.dll というアセンブリがあります。
net5.0\wwwroot\_framework 以下に、フレームワークアセンブリ、dotnet.wasm と呼ばれるランタイム、そしてこれらすべてをまとめる JavaScript ライブラリ blazor.webassembly.js など、必要なものがすべて揃っています。このフォルダは驚くほど大きく、今回のケースでは 34MB を超えています。ファイルは非圧縮形式と .gz 圧縮形式の両方で存在し、すべてが要求されるわけではないため、見た目ほど大きなサイズではありません。必須のファイルの一つはランタイム dotnetwasm.gz で、わずか 1MB 強、非圧縮だと 2.7MB です。
サンプルアプリには、「8.67 MBのリソースを読み込んでいます。このアプリケーションはリンク（ツリーシェイキング）を無効にした状態でビルドされています。公開されたアプリケーションは大幅にサイズが小さくなります。」というメッセージが表示されます。
Blazorのランタイムファイルは驚くほど大きいですが、圧縮と未使用コードの削除により、公開アプリケーションのサイズが小さくなります。
ブラウザに配信されるHTMLは、アプリケーションを包含するdiv要素に過ぎないことも注目すべき点です。実行時には、JavaScriptによってユーザーインターフェースを構成するコントロールがここに配置されます。ただし、これらは標準的なHTMLコントロールであり、ブラックボックスのキャンバス要素ではありません。
Blazor はシングルページ アプリケーション用に設計されており、ブラウザーで .NET コードを実行する Microsoft のブラウザー プラグインである Silverlight を彷彿とさせますが、HTML/CSS ユーザー インターフェイスを備えています。
Blazorアプリケーションモデルには他に2つあります。Blazor Serverはサーバー上で実行され、WebSocket（ASP.NET SignalR）で通信するシンブラウザクライアントをサポートします。プログラミングモデルは同じですが、シンクライアントアプローチであるため、読み込みが高速でWebAssemblyは不要です。IE11でも動作するように設定することも可能です。
さらに、最近 Preview 5 に更新された Mobile Blazor は、Blazor プログラミング モデルを使用しますが、HTML UI または Xamarin フォーム (ネイティブ UI) のいずれかを使用してモバイル アプリケーションとして実行されます。
モバイルバインディングは実験的なものと説明されていますが、Microsoftはこのプロジェクトに真剣に取り組んでいるようです。新しいプレビューでは、SkiaSharpグラフィックス、ジェスチャー認識、デュアルスクリーンサポート、DataPicker、TimePicker、簡素化されたグリッドレイアウトなどが追加されています。
プログラミングモデルは、Razor PagesとWebフォームを組み合わせたような感じです。Razor Pagesよりも使い始めやすいですが、同じRazor構文を使用します。セッション中は状態はブラウザに保持されます。シングルページアプリケーションなので、ユーザーが不用意にページを更新しない限り、Webフォームのようなラウンドトリップの問題は発生しません。
セッション間の状態保持は、サーバー上のデータベースとのやり取りといった標準的なWeb技術によって行われますが、オフラインでの使用を可能にするローカルブラウザストレージのサポートが組み込まれています。PWA（プログレッシブWebアプリケーション）として構築することもオプションとして組み込まれています。開発者は、MicrosoftのIDシステムを使用して、登録、ログイン、認証などの即時サポートを受けることもできます。また、Azure Active Directoryを利用することもできます。
生産性の大きなメリットは、クライアントとサーバー間でコードを共有し、同じように動作させることができることです。開発者は共有クラスを使用してプロジェクトを構築できます。これにより、クライアントとサーバーで同じビジネスオブジェクトを操作しやすくなります。
開発者は、WebAssemblyモデルではすべてのクライアントコードがブラウザ上に保存され、リバースエンジニアリングされる可能性があることに留意する必要があります。つまり、秘密情報や特権APIへのアクセスをブラウザに送信しないように注意する必要があります。シングルページJavaScriptアプリケーションでも同様ですが、サーバー上でコードを実行することに慣れている.NET開発者は、セキュリティ対策を再考する必要があるかもしれません。
.NET 5.0のBlazorは大幅に改善されました。リリースノートによると、「.NET 5のBlazor WebAssemblyは、ほとんどのシナリオで2～3倍高速化されています」という点が大きな特徴です。その他の変更点としては、コンポーネント固有のCSS、コード内でUIフォーカスを設定する機能、ファイルアップロード用の新しいInputFileコンポーネント、Microsoft Identity v2.0などがあります。
Blazor は、Microsoft の複雑な開発者向け製品群の中で、どのような位置づけにあるのでしょうか。Web アプリケーションにとって画期的なものではありません。アプリケーションを .NET アセンブリとして提供することには欠点があり、React のような最新の JavaScript フレームワークには理想的ではありません。WebAssembly と JavaScript の相互運用性は機能しますが、速度が遅くなります。同様に、ASP.NET MVC や Razor Pages に既に慣れている開発者は、クライアントで JavaScript を引き続き実行することに満足するでしょう。しかし、既存の .NET コードが豊富で経験豊かな C# 開発者にとっては、クロスプラットフォーム Web アプリケーション フレームワークへの道が開かれたというメリットがあります。このフレームワークは、Web フォーム® と同等かそれ以上の、迅速なビジネス指向アプリケーションに最適です。
