1

1年ほどのMVCの経験の後、私はまだ1つのことについて混乱しています：ModelState.IsValidでDataAnnotationsを効果的に使用する方法は？簡単なチュートリアルの例では、これはすべて問題なく機能し、それについては質問はありません。しかし、私が次のモデルを持っていると仮定します：

Public Class Movie

    Public Property MovieID As Integer
    Public Property Title As String
    Public Property Year As Integer
    Public Property AddedByUser As String

End Class

これで、データベースにフィールドAddidedByUserが必要になりますが、ユーザーにこれを提供させたくはありませんが、現在ログインしているユーザーに基づくビジネスロジックを提供します。このシナリオでDataAnnotation属性をどのように使用しますか？このフィールドを必須にすると、コントローラーで次のようになります。

 Public Function SaveMovie(ByVal entity as Movie) As ActionResult
    If ModelState.IsValid
       // Save to DB here...
    End If
    Return View(entity)
 End Function

...ビューバインディングにそのフィールドがないため、検証は失敗します。このための隠しフィールドが必要ですか？SaveMovieアクションのカスタムビューモデルを作成する必要がありますか？ビジネスロジックで独自の検証を記述できると思いますが、なぜモデル検証を使用するのでしょうか。おそらくカスタムモデルバインダー？これらのタイプのシナリオを処理するための最良の方法は何ですか？

別のシナリオ例を示すために、挿入と更新の操作と検証の違いについてはどうでしょうか。更新操作には、オブジェクトの主キーが必要です。ただし、インサートの場合はそうではありません。この1つの重要なプロパティのために、挿入と更新用に別々のモデルを用意する必要がありますか？

4

1 に答える 1

1

したがって、これを処理する方法は、ユーザー入力タイプのものにDataAnnotationベースの検証を使用することです。つまり、電子メールアドレス、日付、必須フィールドなどの検証。「健全性チェック」をすばやく実行し、ユーザーエントリを再確認する必要があるもの。

データベースまたはコードが制御するフィールド、つまり主キー、[AddedByUser]プロパティには、ユーザーがこれらのプロパティに直接アクセスしないため、DataAnnotationsを配置しません。したがって、検証チェックを追加する必要はありません。これ。これらのプロパティを更新するのはコードだけなので、なぜそれらを検証するのですか？

より多くの「ビジネスルール」タイプの検証については、すべてのプロパティレベルの検証が成功した後、MVCで実行されるモデルにIValidatableObjectを実装します。プロパティレベルの検証が失敗した場合は実行されないことに注意してください。そして、これは理にかなっています。なぜなら、データが「ダーティ」である場合、より複雑な検証などの実行に進みたくないからです。

お役に立てれば ：）

于 2012-07-14T12:17:34.837 に答える