これは、ASP.NET MVC 2の今後の技術革新に関する一連の記事の第2部であり、そのリリースは間近に迫っています。 この投稿は、ASP.NET MVC 2で追加された検証の強化に関するものです。
ASP.NET MVC 2検証
ユーザーデータ、重要なビジネスロジック、ルールの検証は、ほとんどのWebアプリケーションの重要な要件です。 ASP.NET MVC 2は、ユーザーデータの検証とモデルおよびプレゼンテーションモデルの検証ロジックの実装を大幅に促進する多数の新機能を提供します。 新しい機能は必須のサーバー側検証に焦点を合わせて開発されましたが、JavaScriptを使用してクライアント側に追加で実装することもできます。 ASP.NET MVC 2の検証インフラストラクチャと機能は、次のように実装されています。
1）開発者は、.NET Frameworkに組み込まれたDataAnnotation検証を簡単に活用できます。 DataAnnotationにより、簡単な方法で、最小限のコードを使用してオブジェクトとプロパティに検証ルールを宣言的に追加できます。
2）開発者は、必要に応じて検証エンジンを統合するか、サードパーティのフレームワーク（Castle Validator、EntLib Validation Library）を使用できます。 ASP.NET MVC 2検証機能は、検証アーキテクチャを簡単に拡張できるように設計されています。
これは、拡張の柔軟性を維持しながら、多くの一般的なケースで検証が非常に簡単であることを意味します。
ASP.NET MVC 2およびDataAnnotationで検証を有効にする
新しい機能であるDataAnnotationを使用する簡単なCRUDスクリプトを見てみましょう。 具体的には、「作成」フォームを作成します。これにより、ユーザーに友人が追加されます。
データベースに保存する前に、入力した情報が正しいことを確認し、正しくない場合は、対応するエラーメッセージを表示します。
サーバーとクライアントの両方で検証を行い、コードがDRY原則に準拠していることを確認したい（「繰り返してはいけない」）-検証ルールを1回適用した後、すべてのコントローラー、アクション、およびビューが準拠するそれら。
VS 2010を使用してこのシナリオを実装していますが、VS 2008でもこれを実行できます。
ステップ1：FriendsControllerを作成する（初心者向け、検証なし）
新しいASP.NET MVC 2プロジェクトに単純な「Person」クラスを追加することから始めましょう。
このクラスには、C＃の自動実装プロパティを使用して作成された4つのプロパティがあり、VS 2010以降にVBに登場しました。
プロジェクトに「FriendsController」コントローラークラスを追加し、2つの「Create」アクションメソッドで拡張します。 最初のメソッドは、GETリクエスト/フレンド/作成中に呼び出されます-個人に関するデータを入力するための空のフォームを表示します。 2番目のメソッドは、POSTリクエスト/ FriendsCreateで呼び出されます-入力されたフォームデータをPersonオブジェクトにバインドし、バインド時にエラーをチェックし、エラーがなければ、最終的にデータベースに保存します（データベースの実装は少し後で実装します） 。 フォームに入力されたデータにエラーが含まれている場合、メソッドはエラーフォームとともにユーザーを返します。
コントローラーを作成したら、アクションメソッドの1つを右クリックして[ビューの追加]を選択します。足場を使用して、Personオブジェクトを受け入れる「作成」ビューを作成します。
Visual Studioは、プロジェクトの\ Views \ FriendsディレクトリにCreate.aspxビューファイルを生成します。 強く型付けされたHTMLヘルパーメソッドの使用に注意してください。
そして今、アプリケーションを起動して/ Friends / Createに移動すると、データを入力するための空のフォームが表示されます。
現時点では、間違ったデータを入力しても何も停止しません。
ステップ2：DataAnnotationを使用して検証を追加する
着信データを検証するための簡単なルールでアプリケーションを強化します。 これらのルールは、コントローラーまたはビューではなく、Personモデルに実装します。 このアプローチは、Personオブジェクトが使用されるアプリケーションのシナリオ（たとえば、編集スクリプトを追加する場合）での検証を確実にし、コードがDRY原則に準拠し、コードのさまざまな部分でのルールの重複を排除します。
ASP.NET MVC 2では、開発者は宣言検証属性をモデルに簡単に追加したり、モデルクラスを表示したりできます。これは、後でモデルバインディング操作で使用されます。 これを実際に見るために、いくつかの属性を追加してPersonクラスを更新しましょう。 名前空間「System.ComponentModel.DataAnnotations」に「using」の定義を追加し、検証属性[Required]、[StringLength]、[Range]および[RegularExpression]を使用してPersonプロパティを装飾します
文字列としてのエラーテキストの宣言に注意してください。 リソースファイルで宣言し、ユーザーが選択した言語またはカルチャに応じてローカライズできます。 検証エラーのローカライズの詳細については、 こちらをご覧ください 。
したがって、Personクラスに検証属性を追加したら、アプリケーションを再起動して、サーバーに送信することで、誤って入力されたデータに対する反応を確認しましょう。
どのようにすべてが私たちとまともなものになったかに気付きましたか？ エラーテキストは赤で強調表示され、エラー自体がフィールドの横に表示されます。 入力されたデータはフォームに保存されるため、ユーザーはデータを再入力する必要がありません。 そして、これは一体どうやって起こっているのでしょうか？
仕組みを理解するために、フォームのPOSTリクエストを処理するCreateアクションメソッドを見てみましょう。
HTMLフォームがサーバーにデータを返すと、上記のメソッドが呼び出されます。 アクションメソッドはPersonオブジェクトをパラメーターとして受け取るため、ASP.NET MVCはPersonオブジェクトを作成し、入力フォームデータとその値を自動的に関連付けます。 このプロセスの一部として、PersonオブジェクトのDataAnnotationを検証するためのルールに準拠しているかどうかのチェックが行われます。 チェックが成功した場合、ModelState.IsValidはtrueを返し、結果をデータベースに保存し、ユーザーをホームページに転送します。
検証エラーが発生した場合、アクションメソッドは無効なPersonオブジェクトデータを含むフォームを再び表示します。 これは、上記のコードの最後の行を使用して実装されます。
エラーメッセージは、作成フォームの各<％= Html.TextBoxFor（）％>の後のヘルパーメソッド<％= Html.ValidationMessageFor（）％>のおかげでページに表示されます。 ヘルパーメソッドHtml.ValidationMessageFor（）は、ビューに渡された無効なモデルプロパティに対応するエラーメッセージを表示します。
このパターンの便利さは、コード内での実装の容易さ、およびPersonクラスを検証するためのルールをモデルの外でコードを変更する必要なく追加または変更する簡単さです。 検証ルールを1か所で定義する機能と、アプリケーションの隅でこれらのルールを強制的に使用することにより、コードの重複を回避しながら、最小限の労力でアプリケーションを迅速に開発できます。
ステップ3：クライアント側検証の追加
現時点では、アプリケーションはサーバー側の検証のみをサポートしています。ユーザーは、エラーメッセージが表示される前にサーバーにデータを送信する必要があります。
ASP.NET MVC 2の利点の1つは、サーバーとクライアントの両方の検証をサポートする検証アーキテクチャです。 これを行うには、ビューに2つのJavaScriptスクリプトを追加し、1行のコードを記述するだけです。
3行追加すると、ASP.NET MVC 2はPersonクラスで指定した検証メタデータを使用し、JavaScriptを使用してクライアント側の検証ロジックを作成します。 ユーザーは、別の要素に移動するとすぐにエラーが表示されます。
クライアントの動作を確認するには、アプリケーションを再起動し、最初の3つのテキストフィールドに正しいデータを入力してから、[作成]をクリックしてください。 エラー情報の受信方法に注意してください。サーバーにデータは送信されませんでした。
有効なメールアドレスではないテキストを入力すると、エラーはすぐに「Email required」から「Not a valid email」に変わります。両方のメッセージをPersonクラスの前半で発表しました。
正しい電子メールアドレスを入力すると、エラーメッセージが消え、テキストフィールドの背景が通常の状態に戻ります。
検証ロジックを追加するために、ネイティブJavaScriptコードを記述する必要はありません。 私たちのコードはまだDRY原則に準拠しています。
セキュリティ上の理由から、クライアント側の検証を有効にしている場合でも、検証ルールは常にサーバーで実行されます。 これにより、ハッカーがサーバーをだましてクライアント検証を回避しようとするのを防ぎます。
クライアント側のJavaScript検証は、ASP.NET MVCで使用する任意のフレームワーク/エンジンで機能します。 DataAnnotationの使用に制限はありません。インフラストラクチャ全体はDataAnnotationから独立して動作し、Castle Validator、EntLib Validation Block、またはその他のソリューションと連携できます。
JavaScriptファイルを使用したくない場合は、jQuery検証プラグインに置き換えて使用できます。 ASP.NET MVC Futuresアドオンには、jQuery検証サポートが含まれます。
ステップ4：独自の（電子メール）検証属性の作成
System.ComponentModel.DataAnnotations名前空間には、使用できるいくつかの組み込みの検証属性が含まれています。 [Required]、[StringLength]、[Range]、[RegularExpression]の4つをすでに使用しています。
ただし、独自の検証属性を宣言して使用することはできます。 System.ComponentModel.DataAnnotations名前空間にあるValidationAttributeクラスから継承する完全に新しい属性を作成できます。 または、機能を拡張するだけの場合は、既存の属性に基づいて属性を作成できます。
たとえば、Personクラスのコードをきれいに保つために、電子メールアドレスをチェックするための正規表現をカプセル化する新しい[Email]検証属性を作成します。 簡単な方法は、RegularExpressionクラスから継承し、適切な正規表現を使用してRegularExpressionクラスのコンストラクターを呼び出すことです。
これで、Personクラスを更新し、以前の正規表現の代わりに新しい検証属性[Email]を使用できます。コードがよりクリーンであることに同意します。
独自の検証属性を作成すると、サーバーとクライアントで検証ルールを定義できます。
最後に、オブジェクトの個々のプロパティを参照する独自の属性を作成するために、クラスレベルで検証属性にアクセスできます。 これにより、オブジェクトのいくつかのプロパティと組み合わせてロジックを実装できます。 たとえば、標準のASP.NET MVC 2アプリケーションテンプレート（VS 2010の[ファイル]> [新しいASP.NET MVC 2 Webプロジェクト]）のAccountModels.cs / vbファイルにある[PropertiesMustMatchAttribute]属性を確認できます。
ステップ5：データベースに移動する
そして、友人をデータベースに保存するために必要なロジックを実装しましょう。
現在、古いモデルのC＃クラス（「POCO」クラスと呼ばれることが多い-「古いCLRオブジェクト」）を使用しています。 1つのアプローチは、既存のクラスをデータベースにバインドするコードを個別に記述することです。 これまで、NHibernateのようなオブジェクトリレーショナルプロジェクション（ORM）ベースのソリューションは、POCO通信を強力にサポートしています。 .NET 4でリリースされるADO.NET Entity Framework（EF）は、POCO通信もサポートし、NHibernateと同様に、通信ファイルまたはコンストラクターを使用せずにコードを介して通信する機能もサポートします。
Personオブジェクトがリストされた方法のいずれかでデータベースに接続されていた場合、Personクラスを変更する必要はありません。
しかし、ORM接続に視覚的なツールを使用するとどうなりますか？
現在、Visual Studioを使用する多くの開発者は独自のORM通信ロジックを作成しませんが、VSの組み込みコンストラクターを使用してこの問題を解決しています。
DataAnnotation（またはその他の形式の検証ベースの属性）を使用する場合、しばしば疑問が生じます-「操作するオブジェクトのモデルがGUIコンストラクターを使用して作成される場合、どのようにルールを適用しますか？」 たとえば、POCOスタイルで設計されたPersonクラスを置き換える場合、リンク用のGUIツール-LINQ to SQLまたはADO.NET EFを使用してVisual StudioでPersonalクラスを作成します。
スクリーンショットでは、VS 2010のADO.NET EFコンストラクターを使用して宣言されたPersonクラスを確認できます。上のウィンドウはPersonクラスを定義し、下のウィンドウはリンクエディター、つまりプロパティがPeopleデータベーステーブルにリンクされる方法を表示します。 保存すると、Personクラスが自動的に生成されます。 これは便利です。ただし、変更のたびにファイルを保存する必要があります。これにより、Personクラスが完全に再生成され、宣言された検証属性がすべて失われます。
追加の属性メタデータを自動生成されたクラスに適用するのに役立つソリューションはフレンドクラスです。 実際、検証属性とメタデータ属性を含む別のクラスを作成し、生成されたクラスにバインドして、「MetadataType」属性を生成された部分クラスに適用します。 たとえば、前に使用した検証規則を、LINQ to SQLまたはADO.NET EFコンストラクターを使用して作成されたPersonクラスに適用するには、検証コードをPerson_Validationクラスに渡し、Personクラスに関連付けます。
このオプションは、POCOオプションよりも洗練されていますが、ほとんどのツールまたはVisual Studioのコンストラクターによって生成されたコードを使用するという利点があります。
最後のステップは、友人をデータベースに保存することです。
最後のステップは、使用したアプローチ（POCOまたは何らかのツールで生成されたPersonクラス）に関係なく、有効なFriendオブジェクトをデータベースに保存します。
これを行うには、FriendsControllerクラスの「Todo」ラベルを、データベースに新しい友達を保存する3行のコードで置き換えます。 以下は、ADO.NET EFで動作するFriendsControllerクラスのフルバージョンです。
これで、URL / Friends / Createにアクセスすると、新しいPeopleオブジェクトをデータベースのフレンドリストに簡単に追加できます。
すべてのデータの検証は、クライアントとサーバーで行われます。 検証ルールを簡単に追加/変更/削除することができ、それらはアプリケーションのコントローラーまたは表現によって必ず使用されます。
まとめると
ASP.NET MVC 2を使用すると、検証をWebアプリケーションに簡単に統合できます。 モデルベースの検証アプローチを提供し、異なる場所でのコードの重複を回避し、検証ルールがアプリケーション全体で使用されることを保証します。 DataAnnotationのネイティブサポートにより、すぐに一般的な検証オプションを実装できます。 検証インフラストラクチャの拡張性のサポートにより、さまざまな検証シナリオを実装し、検証フレームワークを接続できます。