3

新しい ASP.NET MVC 2 検証機能を使用すると、ドメイン モデル オブジェクトのプロパティを、DataAnnotations有効な値の条件を説明する属性で修飾できます。はこれを認識しており、コントローラー アクションが呼び出される前に、それに応じDefaultModelBinderて入力します。ModelState.IsValid検証ルールはドメイン モデル内で定義されるため、これはモデル レベルの検証と見なされます。スコット・ガスリーは次のように書いています。

Person オブジェクト内にルールを実装する利点は、Person オブジェクトを使用するアプリケーション内の任意のシナリオを介して検証が確実に実施されることです [...]

厳密に言えば、すべてのアクション メソッドがプロパティをチェックし、その値に応じて異なる動作をする必要があるため、私の意見では、ルールは実際には強制されていません。ModelState.IsValidまた、ルールはモデルで定義されますが、すべてのモデル バインダーが存在する場所であるため、プレゼンテーション レイヤーに適用されます。しかし、これは私が言葉の選択にうるさいだけだと思います（または私が単に間違っているだけです）。

しかし、ドメイン モデル レベルで検証ルールを適用する場合はどうでしょうか。Steven Sanderson は、xVal 検証フレームワークに関する投稿でこのアプローチを使用しており、次のように書いています。

現在、モデル層は、すべての検証およびビジネス ルールを満たさない予約を拒否することで、独自の有効性を強化しています。

彼の例では、コードを使用して無効な予約を行おうとすると、「予約マネージャー」(モデル内に存在する) が特別なビジネス ルールの例外をスローします。したがって、事前に予約の有効性を確認したかどうかに関係なく、消費コードが無効な予約を配置することは不可能ModelState.IsValidです (またはその他のカスタム構造を介して)。

だから私の質問は：

モデルレベルで定義された検証ルールがあると仮定すると、モデル内でも適用する必要がありますか?

(私はドメイン駆動設計の概念にまったく慣れていないので、正しい用語を正確に使用していない場合はご容赦ください。)

4

3 に答える 3

1

モデルレベルで定義された検証ルールがあると仮定すると、それらもモデル内で適用する必要がありますか？

はい。ルールを短絡させる方法を提供すると、短絡することになります。たぶんあなたによるものではないかもしれませんし、すぐにはないかもしれませんが、将来的にはx週間/月/年で他の開発者によって確実になります。

さらに、人為的エラーの要素が常にあります。たぶん、疲れているか、深夜にコーディングしているときに、この検証フラグを誤って読み、実際にレコードを通過させて検証しません。（嘲笑しないでください、私はそれを自分でやったのです！）

モデルによって検証されない限り、レコードがデータベースに到達できないことを常に確認しています。

于 2010-02-12T15:26:56.700 に答える
0

このDataAnnotationsについてもよくわかりません。ただし、モデルがASP.NET MVCプロジェクトにあり、そこから使用されているかどうかに関係なく、どこでも機能するはずです。DataAnnotationsはSystem.ComponentModel.DataAnnotationsの一部であるためです。VSソリューションのコアMVCプロジェクトの外で、すべてのモデルを別々のプロジェクトで定義しているので、これは特に便利です。

于 2010-02-13T18:09:30.067 に答える
0

DataAnnotationsはASP.NETMVC2の便利な機能であり、サーバー側とクライアント側の両方の検証を取得するための優れた安価な方法を提供します。しかし、あなたは大きな弱点を指摘するのは正しいです。しかし、モデルを介して検証を実施することも確かなことではないと思います。2つの問題があります。

問題1：これを実施するためにどのようにしていますか？コンストラクターやセッターなどにあらゆる種類の検証を行うことができますが、これらのルールを回避する必要がある問題に簡単に遭遇する可能性があります。良い例はシリアル化です。通常は回避できますが、オブジェクトの逆シリアル化中に、オブジェクトを一時的に無効な状態にする必要がある場合もあります。別の例は、単純に非常に複雑な階層モデルです（たとえば、親には子が必要であり、その子には親が必要です。鶏が先か卵が先かを同時に構築できないため、明らかに問題があります）。

問題2：より高いレベルの検証ルールについてはどうですか（たとえば、ユーザー名は一意である必要があります）？モデルにこれらのルールを含めることはできません。

一日の終わりには、コードをできるだけクリーンで意図を明らかにするように努力し、物事を十分にテストしておく必要があります。データの整合性を100％完全に保護するモデルベースの検証はまだ見たことがありません。ユーザーがモデルを壊さなくても、最終的には別の開発者が壊します。

于 2010-02-15T05:49:13.257 に答える