- 追加された行はこの色です。
- 削除された行はこの色です。
[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]
-[[戻る>ASP.NET MVC]]
-[[ASP.NET MVC に戻る>ASP.NET MVC]]
* 目次 [#n8bb5f94]
#contents
*概要 [#qe050a8a]
*モジュール化の考え方 [#qfa205f4]
まず、Model と View と Controller の役割について整理する。
-Model: アプリケーションの基礎となるデータ構造、およびそのデータを取得・加工する業務ロジック
-View: Model が保持するデータを参照し、ユーザーに表示するもの
-Controller: ユーザーからの入力を受け取り、Model に対してデータの取得・加工を指示する。~
その結果を受けて、View に表示を指示する。
**ModelとViewの関係 [#u005fdca]
Model (0..1) <---> (1) View
***Model (0) <---> (1) View [#aca38037]
View が、Model が保持するデータを何も表示しない状態。(静的なページなど?)
***Model (1) <---> (1) View [#d22aa019]
View が、Model が保持するデータを参照し、ユーザーに表示している状態。~
ただし、View が参照できるのは「Model のプロパティ」のみであり、View から直接 Model のメソッドが呼ぶことはしない。
**ControllerとViewの関係 [#xc23cbb6]
View (1..*) <---> (1) Controller
***View (1) <---> (1) Controller [#va1ffd01]
ASP.NETのWebFormに近い
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 [#n9abe57a]
[[スキャフォールディング(scaffolding)>ASP.NET MVCの用語#e701b267]]では、この考え方を採用している。
複数の View に対して、1 つの Controller を対応させる考え方。
-スキャフォールディングの時のMとCの関係はCRUDと割り切っているから、~
Model (0..1) <---> (1) View (1..*) <---> (1) Controller となる。
たとえば、受注処理を行うアプリケーションを考えると、「受注作成画面」「受注内容更新画面」「受注削除画面」など、複数の View に分かれていても、同じ「受注」業務に関するリクエストは 1 つの Controller が受け付ける、という考え方。~
[[スキャフォールディング(scaffolding)>ASP.NET MVCの用語#e701b267]]が、この考え方を採用している。~
(1 つの Model に対して、その Model に関するリクエストを受け付ける 1 つの Controller、および CRUD を行う 4 つの View が作成される)
-しかし、1画面に、全てのCRUD機能が詰まっていたら、~
Model (0..1) <---> (1) View (1) <---> (1) Controller と[[WebForm>#va1ffd01]]的になる。
-スキャフォールディングの場合、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 にのみリクエストを送る)
***上記に中立 [#p6842b7c]
1業務、1Controllerなどの考え方でもイイ。
-しかし、1 つの View で、CRUD 全てを実現できる (CRUD ごとに View が分かれない) 場合は、以下のようになる。~
--View (1) <---> (1) Model
--Controller (1) <---> (1) Model
--View (1) <---> (1) Controller
-メリット
--まとまった業務ごとに Controller を作るので、Controller の数を抑えられる。
-デメリット
--複数の View からの処理をすべて 1 つの Controller で受け付けるため、その Controller のコード量が多くなる可能性がある。
**モジュール化の要約 [#j2c8410a]
以下の2つの方式から選択する。
CRUD を 1 つの View で行うか?View を分けるか?など、画面設計にも関係するので、メリット/デメリットを考慮の上、どちらを採用するかを決定する。~
業務画面は、Modelに対応するCRUD画面を生成するスキャフォールディングと異なり~
Controllerが厳密に1つのModelに紐付かないため、画面単位のモジュール化のほうが適合するかもしれない。
***スキャフォールディング方式 [#td62a820]
Model (0..1) <---> (1) View (1..*) <---> (1) Controller
-View (1..*) <---> (1) Model
-Controller (1) <---> (1..*) Model
-View (1..*) <---> (1) Controller
***ASPXライクな1画面1モジュール方式 [#se3008cd]
Model (0..1) <---> View (1) <---> (1) Controller
***View ごとに Controller を作成する方式 [#se3008cd]
-View (1..*) <---> (1) Model
-Controller (1) <---> (1..*) Model
-View (1) <---> (1) Controller
*Controllerの作成 [#ra660e99]
*Controller の作成 [#ra660e99]
**Actionの作成 [#m1334cd3]
**Action の作成 [#m1334cd3]
***URLルーティング [#zed8012c]
ユーザーがブラウザーに URL を入力すると、MVC アプリケーションでは、~
RouteConfig.cs / .vb ファイルに定義されているルーティング規則~
を使用してURL が解析され、コントローラーのパスが特定される。
***URL ルーティング [#zed8012c]
ユーザーがブラウザーに URL を入力すると、RouteConfig.cs / .vb ファイルに定義されているルーティング規則を使用してURL が解析され、コントローラーのパスが特定される。
-コントローラーは、要求を処理する適切なアクション メソッドを決定する。
-既定では、要求の URL は、コントローラー名とアクション名を含むサブパスとして扱われる。
コントローラーは、要求を処理する適切なアクション メソッドを決定する。
既定では、以下のように URL はコントローラー名とアクション名を含む必要がある。~
ここで、「id 値」とはアクションの引数名のことであり、アクションが「id」という名前の引数を持つ場合、URL に記述することでアクションの引数にその値を渡すことができる。~
ただし、アクション名と id 値は省略可能で、アクション名を省略すると、Index アクションが実行される。
***HTTP method [#qa67aa3b]
http://(サーバー名)/(コントローラー名)/(アクション名)/(id 値)
-Get :
***アクションメソッドと HTTP メソッド [#qa67aa3b]
アクションメソッドには、特定の HTTP メソッドのみを受け入れる属性を付与することができる。
--メソッド定義 : [HttpGet]メソッド属性を付与
-[HttpGet] メソッド属性
--概要
---Get メソッドのみ受け入れる。
---それ以外の HTTP メソッドは受け入れない(404 が返る)。
--ユースケース:
---Getで別画面に画面遷移する場合
--ユースケース
---Get で別画面に画面遷移する場合
---入力項目が無い状態で、同一画面内で状態遷移する場合
-Post :~
--メソッド定義 : [HttpPost]メソッド属性を付与
-[HttpPost] メソッド属性
--概要
---Post メソッドのみ受け入れる。
---それ以外の HTTP メソッドは受け入れない(404 が返る)。
--ユースケース
---フォームの入力項目を Controller に Post する場合。
---Post で別画面に画面遷移する場合。
--ユースケース :
---入力項目がある状態でのPostBackする場合。
---Postで別画面に画面遷移する場合。
なお、メソッド属性を指定しなかった場合、そのアクションメソッドはすべての HTTP メソッドを受け入れる。
-,etc. : ,etc.
-メソッド属性を指定しない場合の動作~
全ての HTTP method を受け入れる。
***引数 [#i5d9821b]
***リクエストデータと引数の関連付け [#i5d9821b]
-マップの方法
--POSTやGETのパラメタの名前と一致した引数を定義しておけば、自動的にマップされる。
--POST や GET のパラメタの名前と一致した引数を定義しておけば、自動的にマップされる。
---Get ならクエリ文字列のキー名
---Post ならフォームデータのキー名
--FormCollection を使う (Post の場合のみ)~
<form> の中身がコレクション型として保持されたもの。
--モデルクラスを使う (Post の場合のみ)~
コントローラーとビューで、モデルクラスのデータを双方向バインディングしている場合に使用される。
コントローラーとビューで、モデルクラスのデータを双方向バインディングしている場合に使用される。~
(双方向バインディングについては、[[HTML ヘルパーの使い分け>#c3297525]]を参照。)
-HtmlHelperの生成するパラメタ~
HtmlHelperの生成するパラメタのうち、HtmlHelperが使用するものは~
メソッド引数にマップしない(そのパラメタを自分で使いたければ、マップしても構わない)。
***戻り値 [#v19d2983]
[[アクションメソッドの結果として、クライアントに返す適切なビューを選択する。>#q7da2efc]]
アクションメソッドの結果として、クライアントに返す適切なビューを選択し、表示を指示する。~
詳細は[[アクションメソッドの戻り値>#q7da2efc]]を参照。
*Modelの作成 [#r127e540]
*Model の作成 [#r127e540]
[[モジュール化の考え方>#qfa205f4]]のように、Model には 2 つの意味がある。
-アプリケーションの基礎となるデータ構造~
POCO として作成する。
-そのデータを取得・加工する業務ロジック~
通常の業務ロジッククラスとして作成する。
*Viewの作成 [#m019c385]
*View の作成 [#m019c385]
**Razer、ASPX の使い分け[#m195fa6e]
Razer、ASPX構文でModelを使ってHTMLを生成。
View には、Model のプロパティ参照用、if 文や for 文などの制御用にサーバー処理を埋め込むことができる。~
サーバー処理の記法に、Razer 構文、ASPX 構文がある。
ASPX と Razor の記述方法の比較
||ASPX|Razor|h
|インライン式 (プロパティの値を表示する場合など)|<%: Model.Property1 %>|@Model.Property1|
|インライン式 (エスケープ処理をスキップし、プロパティの値をそのまま表示する場合)|<%= Model.Property1 %>|@Html.Raw(Model.Property1)|
|コードブロック (ロジックを直接 View に記述する場合) (C#)|<% string str = "あいうえお"; %>|@{ string str = "あいうえお"; }|
|コードブロック (ロジックを直接 View に記述する場合) (VB)|<% Dim str As String = "あいうえお" %>|@Code&br; Dim str As String = "あいうえお"&br;End Code|
**BeginForm の使い分け [#sf5c2980]
-HTML(Ajax).BeginFormを記述(そもそもこれはFormタグを生成するヘルパ)
--ここで指定した名前のaction属性を持つFormが生成される。
--これがPOSTされると、その名称のコントローラーのActionに入る。
ASP.NET MVC には、<form> タグを生成する HTML ヘルパーが 2 種類ある。~
BeginForm ヘルパーは引数にコントローラー名、アクション名が付与でき、指定したアクションメソッドにリクエストを送ることができる。
-MicrosoftのASP.NET MVCのAjax.BeginFormは、~
クライアント・サイドのJavaScriptフレームワークとシームレスに連動しているので~
JavaのOSSフレームワークと比べて、かなり実装し易くトラブルも起き難くなっている。
***HTML.BeginForm [#y7008c56]
部分Viewの作成は共通化のため。
通常の <form> タグを生成する場合に使用する。
-全体更新が多数を占める場合(画面設計による)。
-全体更新が多数を占める場合 (アクションメソッドの結果として、View 全体を更新する場合)。
-レガシー技術で構築したい場合
--クライアント・サイドのJavaScriptフレームワークにより~
ブラックボックス化されておりトラブルシュートに心配がある場合がある。
--ただし、JavaのOSSフレームワークと比べてシームレスに連動しているので~
マイクロソフトのサポートを活用して解決できる可能性が高い。
-画面リフレッシュにより、リクエスト・レスポンスのステータスを明確にしたい場合。
***Ajax.BeginForm [#b0eaca55]
部分Viewの作成は更新範囲の定義のため。
<form> タグに Ajax リクエスト用の属性が付与され、リクエストが非同期で処理される。
-部分更新が多数を占める場合(画面設計による)。
-部分更新が多数を占める場合 (アクションメソッドの結果として、View の一部分のみを更新する場合)。
-サーバー側処理が非常に重い業務の場合(Ajax は非同期処理のため)。
-サーバー側処理が非常に重い業務の場合 (Ajax は非同期処理のため)。
-画面入力状態を保持したまま POST 送信したい場合
--ViewstateがサポートされないMVCで情報復元処理を割愛したい場合。
--ViewState がサポートされない MVC で、情報復元処理を割愛したい場合。
-リクエスト・レスポンスのサイズを削減して、性能向上を図りたい場合。
-画面リフレッシュによる、画面のちらつき等をなくしたい場合。
-画面リフレッシュによる、画面のちらつきなどをなくしたい場合。
***参考 [#q5e2db0d]
-ajaxの使いどころ~
http://okwave.jp/qa/q8112782.html
-Html.BeginForm() vs Ajax.BeginForm() in MVC3 - CodeProject~
http://www.codeproject.com/Articles/429164/Html-BeginForm-vs-Ajax-BeginForm-in-MVC3
**Fromタグの切り方 [#j1aac0c9]
-1画面、1Form?
-1画面、複数Form?
**From タグの切り方 [#j1aac0c9]
画面設計によるが、以下を考慮する。
-1 View に対して 1 Form?
-1 View に対して複数 Form?
複数Formの場合はFormをネストさせないこと。~
#HTMLの仕様でFormのネストは禁止されている。
複数 Form の場合は Form をネストさせないこと。~
#HTML の仕様で Form のネストは禁止されている。
**HTML ヘルパーの使い分け [#c3297525]
Html.xxxx と Html.xxxxFor の2種類のHTML ヘルパーがある。
***Html.xxxx [#o7472bbe]
Html.TextBox("Category") のように、プロパティを文字列でマップ指定する場合は、"For" がつかない HTML ヘルパーを使用する。
Html.TextBox("Category") のように、プロパティを文字列でマップ指定する場合は、"For" がつかない HTML ヘルパーを使用する。~
この場合、''Model から View への一方向バインディング''となる。
***Html.xxxxFor [#b6d55f13]
Html.TextBoxFor(model => model.Category) のように、プロパティをラムダ式でマップ指定する場合は、"For" で終わる HTML ヘルパーを使用する。
-...Forを使用してマップ指定すると、ViewとModel間で双方向バインディングされる。
この場合、''Model と View との双方向バインディング''となる。
-とは言え、HTTPを経由しての双方向バインディングになるので、~
処理方式的には、以下の様な処理シーケンスになる。
--POST時に、Formsの情報を自動的にModelに復元する。
--Viewでは復元されたModelから情報を取得して画面を生成する。
ただし、HTTP を経由しての双方向バインディングになるので、処理方式的には、以下のような処理シーケンスになる。
--POST 時に、Html.TextBoxFor などへの入力値を、自動的に Model に復元する。
--Controller は、復元された Model から情報を取得して処理を行う。
***使い分け [#uc043058]
以下のケースで使い分ける。
上記を踏まえて、M/V/C の多重度、および BeginForm を使い分ける。
-ASPXライクな1画面1モジュール方式か?
-スキャフォールディング方式か?
-BeginFormの種類
-M/V/C の多重度
--View ごとに Controller を作成する方式か?
--スキャフォールディング方式か?
-BeginForm の種類
--[[HTML.BeginForm>#y7008c56]]」か?
--[[Ajax.BeginForm>#b0eaca55]]」か?
個人的には、
-ASPXライクな1画面1モジュール方式
-View ごとに Controller を作成する方式
-[[HTML.BeginForm>#y7008c56]]
の場合に最も適合すると考える。
が良いのではないかと考える。
***グリッドの生成 [#j629d667]
WebGridのHTML ヘルパーを使用すると、MVCなのにHTML感を味わえないので、Loopで実装することもある。
ASP.NET MVC でグリッドのある View を作成する場合、以下の 3 種類が考えられる。
-[[WebGrid>https://msdn.microsoft.com/ja-jp/library/system.web.helpers.webgrid.aspx]] クラスを使用する~
ソートやページングが容易に実装できる反面、レンダリング部分は多少ブラックボックスになる
-$lt;table$gt; タグを自前で生成し、<tr> タグをループで実装する~
ASP.NET の Repeater コントロールのようなもの
-jqGrid など、OSS ライブラリを使用する
**View [#j11c45d9]
***全体View [#od7cef82]
-Controller上のActionメソッド(のリージョン)を右クリック、
-Viewを選択するとウィザードが起動する。
View には、画面全体を表す「全体 View」と、画面の一部分のみを表す「部分 View」がある。~
部分 View は、「Partial View」ともいわれ、以下の用途で使われる。
-Viewテンプレート(スキャフォールディング)を選択
-画面の共通化のため~
ASP.NET のユーザーコントロールのように、共通的な画面コンポーネントを部品化しておくもの。
-Ajax.BeginForm の部分更新の範囲を表すため~
Ajax.BeginForm を使用した非同期処理の場合、部分更新の範囲を部分 View で定義する。
--Modelへの対応付け~
テンプレートを使用した場合、対応した自動生成がされる。
*アクションメソッドの戻り値 [#q3d2aae4]
Controller のアクションメソッドは、[[ActionResult>https://msdn.microsoft.com/ja-jp/library/system.web.mvc.actionresult.aspx]] クラスのオブジェクトを返す必要がある。~
ActionResult クラスには、View への指示内容によって、主に以下の種類が存在する。
--オプション
---部分View
---スクリプト・ライブラリ参照
---レイアウト・ページ(個別設定可能)
|種類|概要・用途|コード例|h
|ViewResult|全体 View の表示を指示する。&br();基本的には [[HTML.BeginForm>#y7008c56]] の場合に使用する。|return View("Result");&br();("Result" は全体 View 名)|
|PartialViewResult|部分 View の表示を指示する。&br();基本的には [[Ajax.BeginForm>#b0eaca55]] の場合に使用する。|return PartialView("Result");&br();("Result" は部分 View 名)|
|RedirectResult|指定した URL にリダイレクトする場合に使用する。|return Redirect("http://www.wings.msn.to/");|
|RedirectToActionResult|指定した Controller, Action にリダイレクトする場合に使用する。|return RedirectToAction("Index");|
|RedirectToRouteResult|指定したルート名にリダイレクトする場合に使用する。|return RedirectToRoute("View Product", new { ProductName = <商品名> });|
***部分View [#j4280e7b]
-Viewのフォルダ(Controller名)を右クリック、
-Viewを選択するとウィザードが起動する。
上記以外にも、ファイルダウンロード用の FileResult、JavaScript 実行用の JavaScriptResult などがある。~
詳しくは [[ActionResult クラス>https://msdn.microsoft.com/ja-jp/library/system.web.mvc.actionresult.aspx]]を参照。
-ウィザードの入力
--_XXXViewと名称を付与する。
--部分Viewにチェック入れる。
-親画面から部分Viewを呼び出す。
--親Viewからは、HTMLヘルパのHtml.Partialを使用する。
--PartialViewNameとModelを引数に取る~
親と同じModelを渡すか?Model.Modelを渡すか?どちらでもOK。
-Ajax.BeginFormの場合、親画面から部分ViewをDIVで囲っておく。
*画面遷移の考え方 [#q3d2aae4]
「[[ルーティング>ASP.NET MVCの用語#abe121d3]]」で説明したとおり、~
URLでController+Actionを指定すると指定のControllerのActionが実行される。~
#ただし、Actionを省略した時は、Index(既定のAction)が呼ばれる。
**画面遷移のメソッド [#q7da2efc]
***Viewの選択 [#vfdf6f42]
下記ヘルパ・メソッドを使用する。
-Return View("Result")
--基本的には「[[HTML.BeginForm>#y7008c56]]」の場合に使用する。
--ControllerからViewResultを選択して返す(通常は自画面を選択)。
--Ajax.BeginFormの場合は、画面の初期表示などにも用いられる
-Return PartialView("Result")
--基本的には「[[Ajax.BeginForm>#b0eaca55]]」の場合に使用する。
--ControllerからPartialViewResultを選択して返す。
***画面遷移 [#b9d4724d]
-Redirect遷移方式~
--画面に対応するコントローラーを選択する。
--下記のRedirect系ヘルパ・メソッドを使用する。
-Redirect系ヘルパ・メソッド
--Return Redirect
---指定されたURLにリダイレクト。
---Return Redirect("http://www.wings.msn.to/");
--Return RedirectToAction
---アクション名、コントローラー名、ルート値を使用して、指定されたアクションにリダイレクト。
---Return RedirectToAction("Index")
--Return RedirectToRoute
---ルート名とパラメータ値を引数とし、適切なルーティングフレンドリなURLへリダイレクト
---RedirectToRoute("View Product", new { ProductName = <商品名> });
**画面遷移の方法 [#ycae9af6]
以下の方式が考えられる。
[[モジュール化の要約>#j2c8410a]]で紹介した、[[スキャフォールディング方式>#td62a820]]、[[View ごとに Controller を作成する方式>#se3008cd]]ともに、リクエストの処理フローは以下のようになる。
***POSTでView選択 or 画面遷移 [#tc702cd7]
-BeginFormに任意のController&Actionを指定する。
-POST遷移後、Actionの中でReturn View("Result") ヘルパ・メソッドを使用して画面遷移する。
+View から、対応する Controller にリクエストを送る~
(書こうと思えば、任意の Controller にリクエストを送ることはできるが、View と Controller の関係が複雑になるのでオススメしない)
+Controller はリクエストを受け付け、Model に処理を指示する
+Model は業務ロジックを実行し、データを更新する
+Controller は View に表示を指示する
***自ControllerにPOST後にView選択 or 画面遷移 [#qba5f1f4]
-BeginFormに自Controller&任意のActionを指定する。
ここで、''どの View に表示の指示をするか''によって、使用する ActionResult クラスが変わる。
-その Controller に対応する View に、表示を指示する場合
--ViewResult を使用する
-別の Controller に対応する View に、表示を指示する場合
--RedirectToActionResult または RedirectToRouteResult を使用する
-自ControllerにPOST後、任意のActionの中で
--View選択(Transfer的な)~
Return View("Result") ヘルパ・メソッドを使用して画面遷移する。
--画面遷移(Redirect)~
Return RedirectToAction ヘルパ・メソッドを使用して画面遷移する。
***例外的な遷移 [#nda50fd0]
-例外的にクライアントからGETで遷移するケースもある。
-Link, IFRAME, window.open, etc.
**URLと画面 [#p47f7c6e]
***View (1..*) <---> (1) Controller(スキャフォールディング)+ POST遷移 [#f5f1cb0f]
URLは
-Controllerにだけ対応する。
-Viewにまでは対応しない。
***View (1) <---> (1) Controller(ASPXライク)+ 自ControllerにPOST後に遷移 [#uaea1303]
URLは
-Controllerに対応する。
-Viewにまで対応する。
*フォルダ構成 [#c0d7785c]
**フォルダ分けの意味 [#f6c4f503]
-グルーピングのため。
-名前空間が分かれる。
ASP.NET MVC のテンプレートには、グルーピングを目的に、既定で以下のフォルダ構成となっている。~
それぞれのフォルダには、以下のようにファイルを配置することが推奨されている。
**各フォルダについて [#k32c9ab6]
***App_Start [#s308455d]
-初期設定(起動時)を行うモジュールが配置される。
-例えば、RouteConfigはURLの設定を行う。
|フォルダ名|配置されるファイル|備考|h
|App_Start|起動時に、初期設定を行うモジュール|-|
|Contents|CSS|BundleConfig が使用しているため、既定の CSS ファイルは変更しない|
|Controllers|Controller|-|
|Models|Model|-|
|Scripts|JavaScript|BundleConfig が使用しているため、既定の JavaScript ファイルは変更しない|
|Views|View|対応する Controller 名のフォルダ以下に、View のファイルを配置する&br();例&br();Views&br(); -(コントローラー名)&br(); -Index.cshtml|
***Contents [#x1809e9f]
-CSSはココに置く。
-フォルダ構成は自由
-規定のものは変更しない(BundleConfigで使用しているため)。
***Scripts [#d30cbb78]
-Javascriptはココに置く。
-フォルダ構成は自由
-規定のものは変更しない(BundleConfigで使用しているため)。
***Models [#j9f85022]
-Modelはココに置く。
-フォルダ構成は自由
***Controllers [#i31b0bdb]
-Controllerはココに置く。
-フォルダ構成は自由(ただし、フォルダはURLに反映されない)
-種類
--EntityFramework~
EntityFrameworkを使用する場合に選択する。
--空~
Action→Index(既定のAction)が生成される。
--スキャフォールディング~
スキャフォールディングに対応したActionが生成される。
-Controllers.Action~
HTTPのGETもPOSTも処理できる(メソッド属性で制限できる)。
***Views [#w1a844a4]
-Viewはココに置く。
-Viewsの下位フォルダは作成できない。
--Controller名に対応するフォルダが自動的に生成される。
--補足:XXXXControllerXXXXという所がController名
-規定のページ
--_ViewStart.cshtml
---規定の設定をする、個別に上書き(変更)可能。
---規定では、Layoutに_Layout.cshtmlを設定している。
--_Layout.cshtml
---規定のマスター・ページ(レイアウト・ページ)
---Sharedの_Layout.cshtml(規定のレイアウト)
***Area [#re760150]
なお、Areaを作るとViewsも含めたサブシステム単位のフォルダ分割ができる。~
以下、App_Startのマップルートが追加されるような感じ。
Area (区分) とは、ASP.NET MVC アプリケーションを論理的に分割する仕組みのことである。~
(ASP.NET MVC プロジェクトをシステム全体とすると、Area ごとにサブシステム (のようなもの) に分割できる。~
App_Start のマップルートが追加されるような感じ、と理解すると分かりやすいかもしれない)
*情報の持ち回り・状態管理方式 [#i6db0cb0]
**Viewstate [#s3a7d336]
利用不可能(必要であれば、自前で実装する必要がある)
-ViewState~
利用不可能 (必要であれば、自前で ViewState に相当するものする必要がある)
-Hidden~
使用可能
-Session~
使用可能
**Hidden [#o0afdc6f]
Formの定義・分割が可能なため、持ち回りも共通化困難。
*チェック処理方式 [#hc015ceb]
**クライアント [#i39f251f]
JavaScriptでのチェック
JavaScript でのチェック。~
[[jQuery Validation プラグイン>https://jqueryvalidation.org/]]なども使用可能。
**サーバ [#k1290bb8]
Action内でのチェック
Action メソッド内でのチェック。~
個別にチェックロジックを実装するか、アノテーションを使用したチェックが可能。
**モデルにチェックコードを実装 [#k61bb861]
色々あってよく解らない。
-お楽しみはこれからだ!
--ASP.NET MVC RCの入力検証~
http://takepara.blogspot.jp/2009/02/aspnet-mvc-rc.html
--強力になったDefaultModelBinder~
http://takepara.blogspot.jp/2009/02/defaultmodelbinder.html
--DataAnnotationsだけでの入力検証の盲点~
http://takepara.blogspot.jp/2009/02/dataannotations.html
-こんなこともできるもよう(Entity Frameworkが必要)。
--ASP.NET MVC 3における検証まわりの改善点 (3-4):CodeZine~
http://codezine.jp/article/detail/6176?p=3
--ASP.NET MVC 4 ことはじめ(5)モデルと足場 - アーキテクチャをスマートに。~
http://d.hatena.ne.jp/architect-wat/20130512/1368360044
*脆弱性 [#jd31de6d]
**サニタイジング [#m59baf7f]
-HTMLヘルパーを使用すれば自動。
-Response.Writeの場合は自前。
-HTML ヘルパーを使用すると、自動的にサニタイジングが行われる。
-Model のプロパティを直接 View に表示する場合は、自前でのサニタイジングが必要。
**リクエスト検証 [#ra245005]
-requestValidationModeをMVCでも利用可能。~
-requestValidationMode を MVC でも利用可能。~
http://stackoverflow.com/questions/6206540/what-does-requestvalidationmode-2-0-actually-do