次の方法で共有

ASP.NET Web Forms 開発者向け Blazor の概要

  • [アーティクル]

ヒント

このコンテンツは電子ブック、Azure の「ASP.NET Web Forms 開発者向け Blazor」からの抜粋です。これは .NET Docs から閲覧するか、オフラインで読める無料ダウンロードの PDF としても入手できます。

PDF のダウンロード

Blazor-for-ASP-NET-Web-Forms-Developers eBook cover thumbnail.

ASP.NET Web Forms フレームワークは、2002 年に .NET Framework が最初に出荷されて以降、.NET Web 開発の中心となってきました。 Web の大部分が未成熟であった頃、ASP.NET Web Forms では、デスクトップ開発に使用されていたパターンの多くを採用することで、簡単で生産性の高い Web アプリ作成を実現しました。 ASP.NET Web Forms では、再利用可能な UI コントロールから Web ページをすばやく組み立てることができます。 ユーザーによる操作は、イベントとして自然に処理されます。 Web Forms UI コントロールの豊富なエコシステムが Microsoft およびコントロール ベンダーによって提供されています。 これらのコントロールにより、データ ソースに接続し、高度なデータ視覚化を表示する作業が容易になります。 視覚を重視するユーザー向けに、Web Forms デザイナーには、コントロールを管理するための簡単なドラッグ アンド ドロップ インターフェイスが用意されています。

長年にわたり、Microsoft では、Web 開発の傾向に対処するために新しい ASP.NET ベースの Web フレームワークを導入してきました。 このような Web フレームワークには、ASP.NET MVC、ASP.NET Web ページ、および最近の ASP.NET Core が含まれます。 新しいフレームワークごとに、ASP.NET Web Forms は間もなく衰退すると予測したり、古い時代遅れの Web フレームワークだと批判したりする者もいました。 これらの予測にもかかわらず、引き続き多くの .NET Web 開発者が、ASP.NET Web Forms は作業を完了するためのシンプルで安定した、生産性の高い方法であると見なしています。

執筆時点では、約 50 万の Web 開発者が毎月 ASP.NET Web Forms を使用しています。 ASP.NET Web Forms フレームワークは、10 年前のドキュメント、サンプル、書籍、およびブログ投稿が有用性と関連性を維持できるほどに安定しています。 多くの .NET Web 開発者にとって、.NET が最初に考案されたときと同じように、"ASP.NET" と "ASP.NET Web Forms" は今でも同義です。 他の新しい .NET Web フレームワークと比較した ASP.NET Web Forms の長所と短所に関する議論は続く可能性があります。 ASP.NET Web Forms は、Web アプリを作成するための人気の高いフレームワークであり続けます。

それでも、ソフトウェア開発のイノベーションは減速しません。 すべてのソフトウェア開発者は、新しいテクノロジと傾向を常に把握しておく必要があります。 特に、次の 2 つの傾向は考慮に値します。

  1. オープンソースとクロスプラットフォームへのシフト
  2. クライアントへのアプリ ロジックのシフト

オープンソースかつクロスプラットフォームの .NET

.NET と ASP.NET Web Forms が最初に出荷されたとき、プラットフォーム エコシステムは現在のものとは大きく異なっていました。 デスクトップ市場とサーバー市場は、Windows によって支配されていました。 macOS や Linux のような代替プラットフォームは、勢いを得るのにまだ苦労していました。 ASP.NET Web Forms は、Windows 専用のコンポーネントとして .NET Framework に付属しています。つまり、ASP.NET Web Forms のアプリは Windows Server コンピューターでのみ実行できます。 最新の環境の多くでは、サーバーと開発用コンピューターに異なる種類のプラットフォームを使用するようになったため、多くのユーザーにとってクロスプラットフォームのサポートは絶対的な要件となります。

最新の Web フレームワークもほとんどがオープンソースになっており、さまざまな利点があります。 ユーザーは、1 人のプロジェクト所有者に頼ることなく、バグを修正して機能を追加できます。 オープンソース プロジェクトを使用すると、開発の進行状況や今後の変更に関する透明性が向上します。 オープンソース プロジェクトでは、コミュニティ全体からの貢献を利用でき、オープンソースの支援エコシステムが促進されます。 オープンソースのリスクにもかかわらず、多くのコンシューマーや共同作成者が適切な軽減策を見つけて、オープンソースのエコシステムを安全で合理的な方法で活用しています。 このような軽減策の例としては、共同作成者ライセンス契約、友好的ライセンス、血統スキャン、支持基盤などがあります。

.NET コミュニティでは、クロスプラットフォームのサポートとオープンソースの両方が採用されています。 .NET Core は、Windows、macOS、およびさまざまな Linux ディストリビューションを含む多数のプラットフォームで動作する、.NET のオープンソースかつクロスプラットフォームの実装です。 Xamarin には、オープンソース バージョンの .NET である Mono が用意されています。 Mono は、Android、iOS、およびウォッチやスマート テレビなどの他のさまざまなフォーム ファクターで動作します。 2020 年、Microsoft では .NET 5 をリリースしました。これにより、.NET Core と Mono は「どこでも使える単一の .NET ランタイムとフレームワークであり、統一されたランタイム動作と開発者エクスペリエンスをもつもの」として調整されました。

ASP.NET Web Forms では、オープンソースとクロスプラットフォームのサポートに移行することによって利点が得られるでしょうか。 残念ながら、答えは no です。少なくとも、プラットフォームの他の部分ほどには得られません。 .NET チームは、ASP.NET Web Forms が .NET Core または .NET 8 に移植されないことを明確にしました。 なぜでしょうか。

.NET Core の初期の段階では、ASP.NET Web Forms の移植に取り組みました。 必要な破壊的変更の数が多すぎることがわかりました。 これはまた、たとえ Microsoft でも、同時にサポートできる Web フレームワークの数には限界があると認めたということです。 おそらく、コミュニティ内のだれかが、オープンソースかつクロスプラットフォームのバージョンの ASP.NET Web Forms の作成に取り組むでしょう。 ASP.NET Web Forms のソース コードは、参照形式で公開されています。 しかし、当面の間、ASP.NET Web Forms は Windows 専用のままで、オープンソースのコントリビューション モデルは存在しないようです。 クロスプラットフォームのサポートまたはオープンソースがシナリオにとって重要になる場合は、新しいものを探す必要があります。

これは、ASP.NET Web Forms は "死んだ" ため、もう使用すべきではないという意味でしょうか。 もちろん違います。 .NET Framework が Windows の一部として出荷されている限り、ASP.NET Web Forms はサポートされているフレームワークになります。 多くの Web Forms 開発者にとって、クロスプラットフォームとオープンソースのサポートがないことは、取るに足りない問題です。 クロスプラットフォームのサポート、オープンソース、および .NET Core または .NET 8 の他の新機能を必要としない場合は、Windows で ASP.NET Web Forms を使用し続けても問題ありません。 ASP.NET Web Forms は、今後何年にもわたって、Web アプリを作成するための生産性の高い方法であり続けます。

しかし、考慮に値するもう 1 つの傾向があり、それはクライアントへのシフトです。

クライアント側の Web 開発

ASP.NET Web Forms を含むすべての .NET ベースの Web フレームワークに、従来は "サーバーでレンダリングされる" という 1 つの共通点がありました。 サーバーでレンダリングされた Web アプリでは、ブラウザーからサーバーに対して要求が行われ、サーバーで何らかのコード (ASP.NET アプリの .NET コード) が実行されて応答が生成されます。 この応答はブラウザーに送り返されて処理されます。 このモデルでは、ブラウザーは Web ブラウザー用レンダリング エンジンとして使用されます。 UI を生成し、ビジネス ロジックを実行し、状態を管理するという困難な作業は、サーバー上で行われます。

しかし、ブラウザーは汎用性の高いプラットフォームになっています。 ユーザーのコンピューターの機能に対するアクセスを許可する、増え続けるオープン Web 標準が実装されています。 クライアント デバイスのコンピューティング能力、ストレージ、メモリ、その他のリソースを活用しない理由はありません。 特に UI 操作は、少なくとも部分的にまたは完全にクライアント側で処理されると、よりリッチでインタラクティブな感覚が利点として得られます。 サーバーで処理する必要のあるロジックとデータは、引き続きサーバー側で処理できます。 Web API 呼び出しや、WebSockets などのリアルタイム プロトコルも使用できます。 これらの利点は、Web 開発者が JavaScript を作成する場合に無料で利用できます。 クライアント側の UI フレームワーク (Angular、React、Vue など) は、クライアント側の Web 開発が簡略化されるため、人気が高まっています。 ASP.NET Web Forms 開発者は、クライアントを活用することによってメリットを得ることができます。また、ASP.NET AJAX などの統合された JavaScript フレームワークを使用してすぐにサポートを利用できます。

しかし、2 つの異なるプラットフォームとエコシステム (.NET と JavaScript) の橋渡しにはコストが伴います。 言語、フレームワーク、およびツールが異なる 2 つの平行世界では専門知識が必要です。 クライアントとサーバーの間でコードとロジックを簡単に共有することはできません。その結果、重複とエンジニアリングのオーバーヘッドが発生します。 また、JavaScript エコシステムには猛烈な速度での進化の歴史があり、対応し続けることは困難な場合もあります。 フロントエンド フレームワークとビルド ツールの好みは急速に変化します。 業界では、Grunt から Gulp、さらに Webpack などへの移行が見られました。 jQuery、Knockout、Angular、React、Vue など、フロントエンド フレームワークでも同様の変動が休みなく発生しました。 しかし、ブラウザーでは JavaScript が独占状態にあり、その方面の選択肢はほとんどありませんでした。 そう、Web コミュニティが結集して "奇跡" を起こすまでは。

WebAssembly がニーズを満たす

2015 年に、主要なブラウザー ベンダーが W3C コミュニティ グループで協力して、WebAssembly という新しいオープン Web 標準を作成しました。 WebAssembly は、Web 用のバイト コードです。 コードを WebAssembly にコンパイルできれば、それを任意のプラットフォーム上の任意のブラウザーで、ほぼネイティブの速度で実行できます。 最初の取り組みでは、C/C++ に重点が置かれました。 その結果は、ネイティブの 3D グラフィックス エンジンをプラグインなしで直接ブラウザーで実行するドラマチックなデモでした。 それ以降、WebAssembly は標準化され、すべての主要なブラウザーに実装されています。

WebAssembly での .NET の実行に関する作業は、2017 年後半に発表され、.NET 5 以降のサポートを含めて、2020 年にリリースされました。 .NET コードを直接ブラウザーで実行する機能により、.NET によるフル スタックの Web 開発が可能になります。

Blazor: .NET によるフル スタックの Web 開発

ブラウザーで .NET コードを実行する機能は、それ自体ではクライアント側 Web アプリを作成するためのエンドツーエンドのエクスペリエンスを提供するものではありません。 ここで、Blazor の出番です。 Blazor は、JavaScript ではなく、C# を基盤とするクライアント側の Web UI フレームワークです。 Blazor は、WebAssembly を介してブラウザーで直接実行できます。 ブラウザー プラグインは必要ありません。 また、Blazor アプリでは、サーバー側を .NET で実行し、ブラウザーとのリアルタイム接続を介してすべてのユーザーの操作を処理することもできます。

Blazor には、Visual Studio と Visual Studio Code の優れたツール サポートがあります。 フレームワークには、完全な UI コンポーネント モデルが含まれています。また、次の機能が組み込まれています。

  • フォームと検証
  • 依存関係の挿入
  • クライアント側のルーティング
  • Layouts
  • ブラウザー内デバッグ
  • JavaScript 相互運用

Blazor には、ASP.NET Web Forms との共通点が多くあります。 どちらのフレームワークも、コンポーネント ベースでイベント駆動型のステートフルな UI プログラミング モデルを提供します。 アーキテクチャの主な違いは、ASP.NET Web Forms はサーバー上でのみ実行されるという点です。 Blazor はクライアント上のブラウザーで実行できます。 しかし、ASP.NET Web Forms を使用してきた開発者は、Blazor に多くの点で馴染みやすさを感じるでしょう。 クライアント側開発を活用する手段と .NET のオープンソース、クロスプラットフォームの未来を模索する ASP.NET Web Forms 開発者にとって、Blazor は自然なソリューションです。

本書では、特に ASP.NET Web Forms 開発者向けに Blazor の概要について説明しています。 Blazor の各概念は、ASP.NET Web Forms の類似した機能と手法との関連で示されています。 本書の終わりまでに、次のことを理解できます。

  • Blazor アプリを構築する方法。
  • Blazor の動作のしくみ。
  • Blazor と .NET の関連。
  • 既存の ASP.NET Web Forms アプリを Blazor に移行することが適切な場合は、そのための合理的な戦略。

Blazorの使用を開始する

Blazor は簡単に始めることができます。 https://blazor.net にアクセスし、該当する .NET SDK と Blazor プロジェクト テンプレートをリンクに従ってインストールします。 また、Visual Studio または Visual Studio Code で Blazor ツールを設定するための手順も記載されています。

前へ次へ