データバインドコントロールでモデル検証を有効にする
次に、モデル検証を使用したいデータバインドコントロールでモデル検証を有効にするため、EnableModelValidationプロパティにtrueを設定します（リスト2）。
<asp:FormView ID="LocationsFormView" runat="server" DefaultMode="Insert" ItemType="MRRS.Entity.Location" InsertMethod="InsertLocation" EnableModelValidation="true">
なお、モデル検証の結果を表示するため、ページにはValidationSummaryコントロールも追加しておきましょう（リスト3）。
<asp:HyperLink ID="BackHyperLink" runat="server" NavigateUrl="Locations.aspx">戻る</asp:HyperLink> <asp:ValidationSummary ID="ValidationSummary1" runat="server" ForeColor="Red" />
モデルバインドで実行されるCRUD処理のなかで、検証結果を判定する
最後に、モデル検証の検証結果を追加処理の中で判定し、エラーがあれば処理を中断するようにします（リスト4）。
// 登録処理
public void InsertLocation(Location location)
{
…（中略）…
// モデル検証でエラーがあれば処理中断
if (!ModelState.IsValid) return;
// ビジネスロジックの追加処理実行
var logic = new LocationLogic();
logic.Insert(location);
// 場所参照画面に戻る
Response.Redirect("~/Locations.aspx");
}
検証結果判定には、Page.ModelStateプロパティのIsValidプロパティを使います。モデル検証の中で1つでもエラーがあると、このプロパティはfalseを返します。
なお、ModelStateプロパティは、前回の『ASP.NET 4.5の「モデルバインド」を活用する』でも少し登場しましたが、その役割はモデル検証の検証結果を判定するというものでした。そして前回記事のとおり、AddModelErrorメソッドを使うことで、独自にモデル検証のエラーを追加することもできます。
モデル検証の動作確認
以上でもっともシンプルな形でのモデル検証の実装が終わりました。実際に動作させてみましょう。
まず、場所新規入力画面を開き、場所名が空のまま追加ボタンを押してみましょう（図3）。
すると、サーバーサイドで検証処理が行われ、場所名の必須入力エラーが表示されます（図4）。
ASP.NET Dynamic Dataを用いたクライアントサイド検証
ここまででモデル検証を使った検証処理を見てきましたが、実は重大な問題があります。それは、このままではクライアントサイド検証が行われないことです。検証コントロールを使った場合は、クライアントサイド検証とサーバーサイド検証がともに行われますが、これまでの手順だけだと、モデル検証ではサーバーサイド検証しか行われないのです。
ではどうすればよいのかというと、「ASP.NET Dynamic Data」（以下Dynamic Data）と組み合わせる、がその答えです。
Dynamic Dataとは、データベースの構造を表すモデルクラスを元に、自動的にそのデータを扱う画面を生成する機能です。そのDynamic Dataの機能の一部を使うことで、モデルのフィールドの型と検証属性により、自動的にクライアントサイド検証処理を行うよう、検証サーバーコントロールが実行時に自動生成されます。
Dynamic Dataを用いた例
実際に場所編集画面で実装した例を見てみましょう（リスト5）。場所編集画面では、Dynamic Dataの機能の一部である「Dynamicコントロール」を使っています。
<EditItemTemplate>
<p>
場所名 :
<asp:DynamicControl ID="LocationNameDynamicControl" runat="server"
DataField="LocationName" Mode="Edit" />
</p>
…（中略）…
</EditItemTemplate>
Dynamicコントロールでは、DataFieldプロパティにバインド先のプロパティ名を指定する必要があります。また、本画面は編集画面なので、ModeプロパティにはEditを指定します。他にもInsert、ReadOnlyが選べ、それぞれ追加処理用、表示用の形式が選べます。以上の2つのプロパティを指定することで、バインド先プロパティの型、検証属性に応じて、テキストボックスなどの入力項目と検証検証コントロールを実行時に自動的に生成してくれます。
Dynamic Dataを用いた実行結果
それでは、実際に実行してみましょう。先ほどと同様に、今度は編集画面で場所名を空にして「更新」ボタンをクリックしてみます。すると、サーバーサイドには処理が映らずに、クライアントサイド検証によってエラーが表示されます（図5）。
この時表示されるエラーメッセージは、リスト1でLocationクラスのLocationプロパティに設定したメッセージです。また、エラーとなった項目の脇には"*"によるマークも付きます。
なお、今回はDynamicコントロールを使いましたが、FormViewコントロールではなくDetailsViewコントロールを使用する場合、DynamicFieldクラスが使えますので、興味がある方は試してみてください。また、Dynamic Dataはその動作をカスタマイズすることができます。詳しくは『ASP.NET Dynamic Dataのカスタマイズのポイントを知ろう！』などの記事を参照してください。
