ASP.NET 4.5の「モデル検証」を活用する

実例で学ぶASP.NET 4.5 Webフォーム 新機能活用法 第4回

　ASP.NET 4.5のWebフォームの新機能には、前回紹介したモデルバインドと対で使うための目玉機能がもう一つあります。それが「モデル検証」です。どんなものかサンプルと共に見ていきましょう。

モデル検証とは

　モデル検証は、従来aspxファイルやそのコードビハインドといった、いわゆるView部分に持たせていたユーザーの入力値検証処理を、データバインド先のモデルに持たせるという機能です（図1）。これは、例えば前回連載の『第3回 エラー処理をパターンにはめよう』で取り上げたRequiredFieldValidatorなどの検証サーバーコントロールを使った検証や、独自に実装した単体入力エラー検証を、データバインド対象のモデルに定義できるということです。

図1：モデル検証のイメージ

モデル検証のメリット

　モデル検証のメリットを一言でいえば、検証ロジックがUIから分離され、モデルに集約されることです。従って、サンプルでいえば場所の新規入力処理、編集処理で画面を分けても、検証ロジックは1か所に記載すればよくなります（図2）。

図2：複数画面での検証処理の共有

　また他にも、実例は後述しますが、項目単位の検証処理はSystem.ComponentModel.DataAnnotations名前空間の検証属性によって宣言的に指定するため、比較的コード量を抑えることができることも挙げられます。

モデル検証のデメリット

　逆にデメリットが何かといえば、モデルバインドが前提になっていることです。つまり、モデルバインドが適用できるような画面でなければ、そのメリットを十分に享受できないのです。業務アプリケーションを作成していると、その仕様によっては素直にモデルバインドを適用できないケースもあります。例えば、1つの項目を2つの項目で表したり、データの状態によって動的に項目が変わったりといったケースが考えられます。

　また、業務アプリケーションでは複雑な検証処理が必要なことも少なくありませんが、標準で用意された検証方法は「必須であるか」「等しいか」といった比較的単純な検証しか行えません。

　もちろん、こういったケースでもモデル検証を利用するため、ある程度カスタマイズすることは可能です。今回は紹介しませんが、ASP.NET Dynamic Dataを利用することで動的なUIに対応したり、検証属性を独自に作成して複雑な検証を行わせたりといった方法があります。

　ただ、こういった作りこみのコストは決して小さくはありません。自分とチームが割くことのできるリソースと天秤にかけて、採用を検討するのがよいでしょう。このことは、モデル検証だけでなく、モデルバインド、データバインドについても言えることです。

単純なモデル検証

　それでは、まずは単純な例でモデル検証の基本的な仕組みを学びましょう。

　モデル検証を使用するには、以下の3つの手順が必要です。

1. モデルのフィールドに検証属性を設定する
2. データバインドコントロールでモデル検証を有効にする
3. モデルバインドで実行されるCRUD処理のなかで、検証結果を判定する

　サンプルの場所新規入力画面を例に、それぞれ順番に見ていきましょう。

モデルのフィールドに検証属性を設定する

　まずは、場所新規入力画面のモデルであるMRRS.Entity.Locationクラスのフィールドに、検証属性を設定します（リスト1）。

リスト1 場所のモデルに検証属性を設定（MRRS.Entity\Location.cs）

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;	// (1)

namespace MRRS.Entity
{
  public class Location
  {
    public int LocationId { get; set; }

    [Required(ErrorMessage = "場所名を入力してください。")]	// (2)
    public string LocationName { get; set; }

    public virtual ICollection<MeetingRoom> MeetingRooms { get; set; }
  }
}

（1）検証属性が定義された名前空間をインポートする

　検証属性はSystem.ComponentModel.DataAnnotations名前空間に定義されていますので、using句を使ってインポートします。

（2）場所名に必須検証属性 Required属性を設定する

　場所は必須入力としたいため、Required属性を設定します。ErrorMessageプロパティは、この検証属性による検証に失敗した場合に表示されるメッセージを設定します。

　他に使用できる検証属性には、表1のようなものがあります。なお、ErrorMessageプロパティはすべての検証属性で共通なので、表からは省いています。

表1：モデル検証で使用できる主な検証属性

属性名	説明	主なプロパティ
Compare	他のプロパティと等しいかどうか検証する	OtherProperty:比較対象のプロパティ名
Range	数値が範囲内であるかどうか検証する	Maximum:最大値、Minimum:最小値、 OperandType:検証対象の値の型
StringLength	文字列長が班内であるかどうか検証する	MaximumLength:最大文字列長、 MinimumLenght:最少文字列長
EmailAddress	文字列がEメールアドレスとして妥当かどうか検証する
FileExtensions	ファイル名の拡張子が妥当であるか検証する	Extensions:拡張子
Phone	文字列が電話番号として妥当かどうか検証する
Url	文字列がURLとして妥当かどうか検証する