Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
モジュール化の考え方 †
まず、Model と View と Controller の役割について整理する。
- Model: アプリケーションの基礎となるデータ構造、およびそのデータを取得・加工する業務ロジック
- View: Model が保持するデータを参照し、ユーザーに表示するもの
- Controller: ユーザーからの入力を受け取り、Model に対してデータの取得・加工を指示する。
その結果を受けて、View に表示を指示する。
ModelとViewの関係 †
Model (0..1) <---> (1) View
Model (0) <---> (1) View †
View が、Model が保持するデータを何も表示しない状態。(静的なページなど?)
Model (1) <---> (1) View †
View が、Model が保持するデータを参照し、ユーザーに表示している状態。
ただし、View が参照できるのは「Model のプロパティ」のみであり、View から直接 Model のメソッドが呼ぶことはしない。
ControllerとViewの関係 †
View (1..*) <---> (1) Controller
View (1) <---> (1) Controller †
1 つの View に対して、1 つの Controller を対応させる考え方。
その View からは、対応する Controller へのみリクエストを送る。
Controller の処理の結果は、対応する View にのみ指示を送る、というもの。
Controller の処理の結果を、別の View に表示させたい場合は、
Controller.RedirectToAction? メソッドなどを使用して、その View に対応した Controller に処理をリダイレクトする。
乱暴な言い方をすれば、従来の ASP.NET の WebForm? に近い考え方、と言えるかもしれない。
- 画面 (*.aspx) が、View に相当する
- コードビハインド (*.aspx.cs, *.aspx.vb) が、Controller に相当する
- 画面を遷移するときは、Response.Redirect メソッドを使用して処理をリダイレクトする
- メリット
- 従来の ASP.NET の経験がある人には、とっつきやすい可能性がある。
- デメリット
- Controller クラスの数が膨大になる可能性がある。
View (1..*) <---> (1) Controller †
複数の View に対して、1 つの Controller を対応させる考え方。
たとえば、受注処理を行うアプリケーションを考えると、「受注作成画面」・「受注内容更新画面」・「受注削除画面」など、
複数の View に分かれていても、同じ「受注」業務=受注エンティティに関するリクエストは 1 つの Controller が受け付ける、という考え方。
- スキャフォールディングの場合、M/V/C それぞれの多重度は、以下のようになる。
- View (4) <---> (1) Model
(1 つの Model に対して、CRUD を行う View がそれぞれ作成される)
- Controller (1) <---> (1) Model
(1 つの Model に対して、その Model に関するリクエストを受け付ける Controller が 1 つ作成される)
- View (4) <---> (1) Controller
(CRUD を行う 4 つの View は、1 つの Controller にのみリクエストを送る)
- しかし、1 つの View で、CRUD 全てを実現できる (CRUD ごとに View が分かれない) 場合は、以下のようになる。
- View (1) <---> (1) Model
- Controller (1) <---> (1) Model
- View (1) <---> (1) Controller
- メリット
- まとまった業務ごとに Controller を作るので、Controller の数を抑えられる。
- デメリット
- 複数の View からの処理をすべて 1 つの Controller で受け付けるため、その Controller のコード量が多くなる可能性がある。
モジュール化の要約 †
CRUD を 1 つの View で行うか?View を分けるか?など、画面設計にも関係するので、メリット/デメリットを考慮の上、どちらを採用するかを決定する。
スキャフォールディング方式 †
- View (1..*) <---> (1) Model
- Controller (1) <---> (1..*) Model
- View (1..*) <---> (1) Controller
View ごとに Controller を作成する方式 †
- View (1..*) <---> (1) Model
- Controller (1) <---> (1..*) Model
- View (1) <---> (1) Controller
Controller の作成 †
モジュール化 †
モジュール化の要約で紹介した、
何れかの方針に合わせて、Controllerを作成する。
利用可能な属性 †
HTTP メソッド属性 †
Action Methodには、特定の HTTP メソッドのみを受け入れる属性を付与することができる。
AcceptVerbs? 属性([AcceptVerbs?(HttpVerbs?.Post)] 等)が用意されていたが、
MVC 2 からはHttpGet?, HttpPost?, HttpPut?, HttpDelete?という4つの属性が追加された。
- [HttpGet?] メソッド属性
- 概要
- Get メソッドのみ受け入れる。
- それ以外の HTTP メソッドは受け入れない(404 が返る)。
- ユースケース
- Get で別画面に画面遷移する場合
- 入力項目が無い状態で、同一画面内で状態遷移する場合
- [HttpPost?] メソッド属性
- 概要
- Post メソッドのみ受け入れる。
- それ以外の HTTP メソッドは受け入れない(404 が返る)。
- ユースケース
- フォームの入力項目を Controller に Post する場合。
- Post で別画面に画面遷移する場合。
なお、メソッド属性を指定しなかった場合、
そのAction Methodはすべての HTTP メソッドを受け入れる。
ActionName?属性 †
Action Method名と、外部に公開するAction Nameとを別にする。
例えば
項番 | Action Method名 | ActionName? | 処理の内容 |
1 | Delete | Delete | 削除画面の初期表示処理 |
2 | DeleteConfirmed? | Delete | 削除処理の実行 |
ValidateAntiForgeryToken?属性 †
CSRF対策に使用する。
Model の作成 †
モジュール化 †
モジュール化の考え方のように、Model には 2 つの意味がある。
- アプリケーションの基礎となるデータ構造
- POCO として作成する。
- XXXXViewModel?という名称を付与する。
利用可能な属性 †
テンプレート・ヘルパーと呼ばれる(System.ComponentModel?.DataAnnotations?)。
ViewやControllerのスキャフォールディング生成の動作を制御する属性。
DataType?属性 †
型情報
[DataType(DataType.XXXX)]
Display属性 †
表示名(Label表示用のViewヘルパーに使用される)
- Name
- [DisplayName?("xxxx")]
- [Display(Name = "xxxx")]
- ResourcesType?(国際化対応用)
- [Display(Name = "xxxx", ResourceType? = typeof(yyyy))]
DisplayFormat?属性 †
フォーマットの指定。
[DisplayFormat(DataFormatXXXX="YYYY")]
UIHint属性 †
- 独自の表示/編集テンプレートを準備する。
- 例えばDateTime?型を指定したEditorFor?で
使用するjQuery UIのDatepickerを適用する。
DisplayColumn?属性 †
- Model間のRelationを設定した際、Modelの表示名に使用しているColumn。
- Model間のRelationは、オブジェクト参照で設定する。
View の作成 †
モジュール化 †
- View には、
- 画面全体を表す「全体 View」と、
- 画面の一部分のみを表す「部分 View」がある。
全体 View †
通常のViewはコレ。
部分 View †
部分 View は、「Partial View」ともいわれ、以下の用途で使われる。
- 画面の共通化のため
ASP.NET のユーザーコントロールのように、共通的な画面コンポーネントを部品化しておくもの。
- Ajax.BeginForm? の部分更新の範囲を表すため
Ajax.BeginForm? を使用した非同期処理の場合、部分更新の範囲を部分 View で定義する。
Razer、ASPX の使い分け †
View には、Model のプロパティ参照用、if 文や for 文などの制御用にサーバー処理を埋め込むことができる。
サーバー処理の記法に、Razer 構文、ASPX 構文がある。
| ASPX | Razor |
インライン式 (プロパティの値を表示する場合など) | <%: Model.Property1 %> | @Model.Property1 |
インライン式 (エスケープ処理をスキップし、プロパティの値をそのまま表示する場合) | <%= Model.Property1 %> | @Html.Raw(Model.Property1) |
コードブロック (ロジックを直接 View に記述する場合) (C#) | <% string str = "あいうえお"; %> | @{ string str = "あいうえお"; } |
コードブロック (ロジックを直接 View に記述する場合) (VB) | <% Dim str As String = "あいうえお" %> | @Code Dim str As String = "あいうえお" End Code |
BeginForm? の使い分け †
ASP.NET MVC には、<form> タグを生成する Viewヘルパーが 2 種類ある。
BeginForm? ヘルパーは引数にコントローラー名、アクション名が付与でき、指定したアクションメソッドにリクエストを送ることができる。
HTML.BeginForm? †
通常の <form> タグを生成する場合に使用する。
- 全体更新が多数を占める場合 (アクションメソッドの結果として、View 全体を更新する場合)。
- 画面リフレッシュにより、リクエスト・レスポンスのステータスを明確にしたい場合。
Ajax.BeginForm? †
<form> タグに Ajax リクエスト用の属性が付与され、リクエストが非同期で処理される。
- 部分更新が多数を占める場合 (アクションメソッドの結果として、View の一部分のみを更新する場合)。
- サーバー側処理が非常に重い業務の場合 (Ajax は非同期処理のため)。
- 画面入力状態を保持したまま POST 送信したい場合
- ViewState? がサポートされない MVC で、情報復元処理を割愛したい場合。
- リクエスト・レスポンスのサイズを削減して、性能向上を図りたい場合。
- 画面リフレッシュによる、画面のちらつきなどをなくしたい場合。
参考 †
From タグの切り方 †
画面設計によるが、以下を考慮する。
- 1 View に対して 1 Form?
- 1 View に対して複数 Form?
複数 Form の場合は Form をネストさせないこと。
#HTML の仕様で Form のネストは禁止されている。
Viewヘルパーの使い分け †
HTMLヘルパー(Html.xxxx と Html.xxxxFor †
- Html.xxxxFor
- ポスト時にModelデータを復元する場合。
- 例えばエラー発生時に、自画面の再表示(≒ポストバック)をする場合。
- Html.xxxx
上記以外は、Html.xxxxで良い。
GridView?的な一覧(グリッド)生成用のViewヘルパー †
ASP.NET MVC で一覧(グリッド)のある View を作成する場合、以下の 3 種類が考えられる。
- WebGrid クラスを使用する
ソートやページングが容易に実装できる反面、レンダリング部分は多少ブラックボックスになる
- <table> タグを自前で生成し、<tr> タグをループで実装する
ASP.NET の Repeater コントロールのような処理の実装方法(Razorなぶん楽)。
テンプレートに対応したViewヘルパー †
- Viewヘルパー
- EditFor?
- HTMLヘルパーの第二引数でテンプレートを指定できる。
- UIHint属性で指定したテンプレートが使用される。
属性の優先度は、UIHint属性 -> DataType?属性 -> 実際のデータ型
- DisplayForModel?、EditForModel?
- テンプレート名とテンプレート配置場所
- DisplayTemplates?
- EditorTemplates?
カスタムViewヘルパー(カスタム・コントロールみたいな) †
画面遷移 †
モジュール化の要約で紹介した、
共に、画面遷移の処理フローは以下のようになる。
処理フロー †
- View から、対応する Controller にリクエストを送る
- Controller はリクエストを受け付け、Model に処理を指示する
- Model は業務ロジックを実行し、データを更新する
- Controller は View に表示を指示する
実装方法 †
なお、1つの View が、任意の Controller にPOSTリクエストを送る
ASP.NET Web Formsの「ページ間ポスティング」的な実装も書けるが、
View と Controller の関係が複雑になるのでオススメしない。
従って、上記の「4.」で、どの View に表示の指示をするかによって、
使用する ActionResult? クラスを下記のように変える様に実装する。
- その Controller に対応する View に、表示を指示する場合
- 別の Controller に対応する View に、表示を指示する場合
- RedirectToActionResult? または RedirectToRouteResult? を使用する
フォルダ構成 †
既定のフォルダ構成 †
ASP.NET MVC のテンプレートには、グルーピングを目的に、既定で以下のフォルダ構成となっている。
それぞれのフォルダには、以下のようにファイルを配置することが推奨されている。
フォルダ名 | 配置されるファイル | 備考 |
App_Start | 起動時に、初期設定を行うモジュール | - |
Contents | CSS | BundleConfig? が使用しているため、既定の CSS ファイルは変更しない |
Controllers | Controller | - |
Models | Model | - |
Scripts | JavaScript | BundleConfig? が使用しているため、既定の JavaScript ファイルは変更しない |
Views | View | 対応する Controller 名のフォルダ以下に、View のファイルを配置する 例 Views\(コントローラー名)\Index.cshtml |
Area (区分)による分割 †
Area (区分) とは、ASP.NET MVC アプリケーションを論理的に分割する仕組みのことである。
(ASP.NET MVC プロジェクトをシステム全体とすると、Area ごとにサブシステム (のようなもの) に分割できる。
App_Start のマップルートが追加されるような感じ、と理解すると分かりやすいかもしれない)
情報の持ち回り・状態管理方式 †
ViewState? †
利用不可能
必要であれば、
ViewState?相当の状態保存処理を独自実装する必要がある
(For付きのViewヘルパー(Html.xxxxFor)を使用する)。
Hidden †
使用可能
Session †
使用可能
チェック処理方式 †
クライアント †
JavaScript でのチェック。
jQuery Validation プラグインなども使用可能。
サーバ †
Action メソッド内でのチェック。
個別にチェックロジックを実装するか、アノテーションを使用したチェックが可能。
- こんなこともできるもよう(Entity Frameworkが必要)。
脆弱性 †
サニタイジング †
- HTML ヘルパーを使用すると、自動的にサニタイジングが行われる。
- Model のプロパティを直接 View に表示する場合は、自前でのサニタイジングが必要。
リクエスト検証 †
Tags: :ASP.NET MVC