ASP.NET MVC 概要

提供元: Microsoft

ASP.NET MVC アプリケーションと ASP.NET Web Forms アプリケーションの違いについて説明します。 ASP.NET MVC アプリケーションをビルドすべき場合を判断する方法について説明します。

Model-View-Controller (MVC) アーキテクチャ パターンでは、アプリケーションがモデル、ビュー、およびコントローラーという 3 つの主要なコンポーネントに分離されます。 ASP.NET MVC フレームワークは、MVC ベースの Web アプリケーションを作成するための ASP.NET Web Forms パターンの代替手段を提供します。 ASP.NET MVC フレームワークは、(Web Forms ベースのアプリケーションと同様に) マスター ページやメンバーシップ ベースの認証などの ASP.NET の既存の機能と統合された、軽量で高度なテストが可能なプレゼンテーション フレームワークです。 MVC フレームワークは System.Web.Mvc 名前空間で 定義されており、基本的でサポートされている System.Web 名前空間の部分です。

MVC は、多くの開発者が使い慣れている標準のデザイン パターンです。 Web アプリケーションの種類によって、MVC フレームワークの利点を活用できる場合もあれば、 Web Forms とポストバックに基づく従来の ASP.NET アプリケーション パターンを引き続き使用する場合もあります。 さらに、どちらかの方法に限定せず、2 つの方法を組み合わせることもあります。

MVC フレームワークには、次のコンポーネントが含まれます。

図 01: パラメーター値を必要とするコントローラー アクションの呼び出し (フルサイズの画像を表示するにはここをクリック)

• モデル。 モデル オブジェクトは、アプリケーションのデータ ドメインのロジックを実装する部分です。 多くの場合、モデル オブジェクトでは、モデルの状態をデータベースから取得したり、データベースに格納したりします。 たとえば、Product オブジェクトは、データベースから情報を取得して操作し、更新された情報を SQL Server の Products テーブルに書き戻す場合があります。

小規模なアプリケーションでは、モデルは物理的な分離ではなく、概念的な分離である場合があります。 たとえば、アプリケーションがデータ セットのみを読み取ってビューに送信する場合、アプリケーションには物理モデル レイヤーや関連付けられたクラスがありません。 その場合、データ セットがモデル オブジェクトの役割を担います。

• "ビュー"。 ビューは、アプリケーションのユーザー インターフェイス (UI) を表示するコンポーネントです。 通常、この UI はモデル データから作成されます。 たとえば、Products オブジェクトの現在の状態に基づいてテキスト ボックス、ドロップダウン リスト、およびチェック ボックスを表示する Products テーブルの編集ビューがあります。

• コントローラー。 コントローラーは、ユーザーとの対話を処理し、モデルと連携して動作し、UI を表示するためにレンダリングされるビューを最終的に選択するコンポーネントです。 MVC アプリケーションでは、ビューは情報のみを表示し、コントローラーがユーザーの入力と操作を処理して応答します。 たとえば、コントローラーは、クエリ文字列の値を処理し、それらの値をモデルに渡します。次に、モデルがそれらの値を使用してデータベースを照会します。

MVC パターンを使用すると、アプリケーションのそれぞれの側面 (入力ロジック、ビジネス ロジック、および UI ロジック) を分離するアプリケーションを作成できます。同時に、これらの要素間には疎結合が維持されます。 それぞれのロジックをアプリケーションのどのコンポーネントに配置するかは、このパターンが指定します。 UI ロジックはビューに属しています。 入力ロジックはコントローラーに属しています。 ビジネス ロジックはモデルに属しています。 このように分離することで、実装の 1 つの側面に専念できるため、アプリケーションを構築するときの複雑さに対応しやすくなります。 たとえば、ビジネス ロジックに依存することなく、ビューに専念できます。

開発が簡素化されるだけでなく、MVC パターンでは、Web Forms ベースの ASP.NET Web アプリケーションをテストする場合に比べて、アプリケーションのテストが簡素化されます。 たとえば、Web Forms ベースの ASP.NET Web アプリケーションでは、出力の表示とユーザー入力への応答の両方に単一のクラスが使用されます。 Web Forms ベースの ASP.NET アプリケーション用の自動テストを作成するのは容易ではありません。これは、個々のページをテストするために、ページ クラス、そのすべての子コントロール、およびアプリケーション内のその他の依存クラスをインスタンス化する必要があるからです。 ページを実行するために多くのクラスがインスタンス化されるため、アプリケーションの特定の部分のみを対象にしたテストを作成するのは困難です。 したがって、Web Forms ベースの ASP.NET アプリケーションのテストは、MVC アプリケーションのテストよりも実装が難しくなります。 さらに、Web Forms ベースの ASP.NET アプリケーションのテストには Web サーバーが必要です。 MVC フレームワークでは、コンポーネントが分離され、インターフェイスが多用されます。そのため、各コンポーネントをフレームワークの他の部分から切り離してテストできます。

MVC アプリケーションは、3 つの主要なコンポーネント間の結合が弱いため、並行開発にも適しています。 たとえば、1 人の開発者がビューで作業でき、2 人目の開発者はコントローラー ロジックに取り組み、3 人目の開発者はモデルのビジネス ロジックに集中できます。

MVC アプリケーションを作成する場合の判断

Web アプリケーションの実装時に ASP.NET MVC フレームワークと ASP.NET Web Forms モデルのどちらを使用するかは、慎重に検討する必要があります。 MVC フレームワークは、Web Forms モデルに取って代わるものではありません。どちらのフレームワークも Web アプリケーションに使用できます。 (Web Forms ベースの既存のアプリケーションは、これまでと同じように動作します。)

特定の Web サイトで MVC フレームワークと Web Forms モデルのどちらを使用するか判断するときは、それぞれの方法の利点を比較検討します。

MVC ベースの Web アプリケーションの利点

ASP.NET MVC フレームワークには次のような利点があります。

• アプリケーションがモデル、ビュー、およびコントローラーに分離されるため、複雑さが軽減されます。
• ビュー状態やサーバー ベースのフォームは使用されません。 このため、MVC フレームワークは、アプリケーションの動作を完全に制御する必要がある開発者に向いています。
• Web アプリケーションの要求を単一のコントローラーで処理するフロント コントローラー パターンが使用されます。 これにより、多機能なルーティング インフラストラクチャをサポートするアプリケーションを設計できます。 詳細については、「フロント コントローラー」を参照してください。
• テスト駆動開発 (TDD) のサポートが向上します。
• これは、アプリケーションの動作を高度に制御する必要がある開発者や Web デザイナーの大規模なチームによってサポートされている Web アプリケーションに適しています。

Web Forms ベースの Web アプリケーションの利点

Web Forms ベースのフレームワークには、次のような利点があります。

• HTTP 経由で状態を保持するイベント モデルがサポートされます。これは、基幹業務 Web アプリケーションの開発に有用です。 Web Forms ベースのアプリケーションでは、数多くのサーバー コントロールでサポートされているさまざまなイベントを使用できます。
• 個々のページに機能を追加するページ コントローラー パターンが使用されます。 詳細については、「ページ コントローラー」を参照してください。
• ビュー状態またはサーバー ベースのフォームを使用するため、状態情報の管理が容易になります。
• Web 開発者とデザイナーで構成される小規模なチームで RAD (Rapid Application Development) のための多数のコンポーネントを活用する場合に適しています。
• 一般に、コンポーネント (Page クラス、コントロールなど) は緊密に統合されており、通常は MVC モデルよりも必要なコードが少ないため、アプリケーション開発の複雑さが少なくなります。

ASP.NET MVC フレームワークの機能

ASP.NET MVC フレームワークには次の機能があります。

• 既定では、アプリケーション タスク (入力ロジック、ビジネス ロジック、UI ロジック)、テスト可能性、テスト駆動開発 (TDD) の分離。 MVC フレームワークの主要なコントラクトはすべてインターフェイス ベースであり、モック オブジェクトを使用してテストできます。モック オブジェクトとは、アプリケーションの実際のオブジェクトの動作を模倣するシミュレーション用のオブジェクトです。 アプリケーションの単体テストを実行するときに ASP.NET プロセスでコントローラーを実行する必要がないため、高速で柔軟性のある単体テストを実行できます。 .NET Framework と互換性がある任意の単体テスト フレームワークを使用できます。
• 拡張性のあるプラグ可能なフレームワーク。 ASP.NET MVC フレームワークのコンポーネントは、置き換えやカスタマイズが簡単にできるように設計されています。 独自のビュー エンジン、URL ルーティング ポリシー、アクション メソッド パラメーターのシリアル化などのコンポーネントをプラグインできます。 ASP.NET MVC フレームワークでは、依存性挿入 (DI: Dependency Injection) および制御の反転 (IOC: Inversion of Control) というコンテナー モデルの使用もサポートされます。 DI を使用すると、クラスに依存してオブジェクト自体を作成する代わりに、オブジェクトをクラスに挿入できます。 IOC は、オブジェクトが他のオブジェクトを必要とする場合に、構成ファイルなどの外部ソースから他のオブジェクトを取得することを指定します。 これにより、テストが簡単になります。
• わかりやすく検索可能な URL を持つアプリケーションを構築できる強力な URL マッピング コンポーネント。 URL にファイル名拡張子を含める必要がなく、また、検索エンジンの最適化 (SEO) や Representational State Transfer (REST) のアドレス指定に適した URL 命名パターンをサポートするように設計されています。
• 既存の ASP.NET ページ (.aspx ファイル)、ユーザー コントロール (.ascx ファイル)、およびマスター ページ (.master ファイル) の各マークアップ ファイルのマークアップをビュー テンプレートとして使用する機能。 入れ子になったマスター ページ、インライン式 (<%= %>)、宣言型のサーバー コントロール、テンプレート、データ バインディング、ローカリゼーションなど、ASP.NET の既存の機能を ASP.NET MVC フレームワークで使用できます。
• ASP.NET の既存の機能のサポート。 ASP.NET MVC では、フォーム認証と Windows 認証、URL 承認、メンバーシップとロール、出力キャッシュとデータ キャッシュ、セッションとプロファイルの状態管理、状態監視、構成システム、プロバイダー アーキテクチャなどの機能を使用できます。