4

POCOを使用してEF4でMVC3アプリケーションを作成しています。EFエンティティに検証属性を追加しました。ここで、ビューを作成しているときに、ビューモデルを使用したいと思います（おそらく、AutoMapperを使用してビューを埋めます）。

私が遭遇した問題は、DRYプリンシパルに違反するビューモデルの検証属性を再定義する必要があることです。たとえば、フィールドのサイズを変更する場合は、POCOとそれを使用するビューモデルの両方でMaxLength属性を変更する必要があります。

POCOからビューモデルに検証ルールをマッピングするためのトリッキーな方法はありますか？

4

3 に答える 3

5

個人的には、ビューモデルで検証を行います。これは、コントローラーがビューから受け取るものであり、ユーザー入力を含むクラスです。サーフェス検証とビジネス検証の2種類の検証ルールを区別します。必須フィールド、適切な形式などのルールをビューモデルで適用する必要がありますが、特定の名前のユーザーなどのビジネスルールがデータベースにすでに存在する場合は、モデルで検証する必要があります。

また、異なるビューモデルを同じモデルにマッピングすることもできますが、ビュー検証ルールに基づいて異なる場合があります。このため、ビューモデルでまったく同じ検証ルールを使用することはできません。

于 2011-01-01T17:20:47.877 に答える
2

抽象化を行う1つのアプローチは、必要な他のビュー情報を含め、ビジネスモデルクラスのViewModelを「構成」することです。

class MyObject 
{
    public int ID {get;set}

    [Required]
    [StringLength(512)]     
    public string Name {get;set;}

}

class MyViewModel // ViewModel for a specific view 
{
    public MyObject MyModel {get;set;}        // the model that is being edited 

    // other data the view might need, set by the controller 
    public string SomeMessage { get; set; }
    public List<SomeObject> SomeObjects {get;set;} /// e.g. for a drop-down list

}

次に、ビューでViewModelを適宜参照します。

@model My.Namespace.MyViewModel


Hello @model.MyModel.Name !!!

このように、ビジネスクラスの検証やデータ注釈を1か所で指定するだけです。

別の検証が必要な場合は、検証ロジックを選択的に適用するための戦略が必要になります。

于 2011-03-09T21:56:19.227 に答える
1

私もこれに苦労しており、DRYに違反していることに同意します。私はこれについての最近の質問をここに投稿し、かなりの反発を受けました。

実際のアプリケーションでは、完璧なDRYを取得することはできません。時には、盲目的にそれに固執しようとするよりも、原則に違反することでより良い結果が得られることがあります。

編集：

また、DRYが単一責任原則（SRP）に違反する可能性があると考える人もいるかもしれません。同様のコードを再利用することで、コードに複数のことを実行させることになります。データモデルとビューモデルの目的が異なり、したがって責任も異なるという事実を考えると、それらを1つのモデルにまとめることはSRPに違反します。つまり、データモデルをビューモデルにすることで、2つの異なる責任が発生します。

これで、この点に関してSRPとDRYを調整する可能性のあるいくつかの方法を考えることができますが、ある時点で、コストによるメリットを比較検討する必要があります。

于 2011-01-01T17:40:35.187 に答える