Web Formの問題点
単体テストを自動化しづらい
Webフォームは基本的にPagesクラス
を中心にしたFWであるためPagesクラスを直接インスタンス化できないのでテストにあたりサーバ環境の準備が必要になる。
また、イベントハンドラが原則としてUIから呼び出されてしか動かないこともテストの自動化を妨げる要因
Web Form 固有の概念が多い
サーバコントロール、イベントどぶリン、ポストハック、ビューステートなどの固有の概念が慣れてないとハードルになる
出力の制御が難しい
サーバーコントロールの目的は、出力をブラックボックス化することだが、細かな出力の制御が難しい
ASP.NET MVCの特徴
MVCを採用
| 要素 | 概要 |
|---|---|
| Model | データベースのアクセス、データ処理、ビジネスロジック。UI変更の影響を受けずらい |
| View | UI.データの入出力フォームや処理結果の表示などフロントエンド |
| Controller | ModelとViewの仲介。ViewからのデータをModelに渡し、Modelでの処理結果をViewに渡す |
フロントコントローラーを採用
個々のページでリクエストを受け、処理結果もページからクライアントに返す方式をページコントローラーとよぶ。
対してAPS.NET MVCではフロントコントローラー方式を採用する。
フロントコントローラーとはクライアントからのリクエストをまずフロントコントローラーで受けて、それから各クラスへ振り分ける方法のこと。
また、リクエストURLに応じた処理の受け渡し先を決定することをルーティングとよぶ。
単体テストを自動化しやすい
各クラスがインスタンス化できるので単体テストが容易
サーバーコントロールを利用しない
イベントドブリンやポストバック、ビューステートという概念がなく、コード埋め込みのアノテーションを利用してHTMLを出力する。
Webフォームの知識を生かせる
セクションやクッキー、キャッシュといった基本的な機能の大部分ではASP.NETの知識を流用できる。
APS.NET MVCの主な機能
- ルーティング
- 認証やキャッシュ、例外処理などのフィルター
- 入力データを処理するモデルバインド
- コントローラーの処理結果を管理するActionResultオブジェクト
- ビュー開発を効率化する種種のヘルパーメソッド
- アプリケーションの骨格を自動生成するScaffolfing機能