2010-12-07 8 views
1

MVCアプリケーションには、ドメインモデルが定義されており、各モデルは独自のビジネスルールチェックを実行します。MVCアプリケーションでは、ビジネス・モデルの検証をビュー・モデルおよび/またはコントローラに複製する必要がありますか?

私の質問は、ビジネス・ルールもビュー・モデルまたはコントローラでレプリケートする必要がありますか、またはモデルで検証エラーを生成するだけでよいのでしょうか。

私たちが話しているバリデーションはクライアント側ではできないと仮定し、ビューモデルのプロパティにバリデーション属性を追加することで行うことができる単純なフィールド検証よりも複雑です。

モデルがすべての検証を処理できるようにすることの問題は、生成するエラーメッセージが、その結合された特定のビューには適していない可能性があります。たとえば、フィールド名が正しくない可能性があります。また、ドメインモデルのプロパティ名ではなく、ビューモデルプロパティ名を使用してModelStateにエラーを追加する必要があります。

のviewmodel /コントローラに同じビジネス・ルールの検証を追加することに伴う問題は、明らかな重複メンテナンスの問題であり、それは私のドメインモデルでの検証が本当に親切のそれは少し無意味になり、エラーを生成してはならないことを意味します。

どのように人々は通常これを処理するのですか?

答えて

1

私がこのシナリオで使用するのによく使用した解決策は、モデル(または私の場合は通常は検証ライブラリ)で検証することですが、このような標準的な検証エラーをキャッチできるエラーをコントローラに追加することです:

public ActionResult Submit(String email) 
{ 
     string errorMessage = ""; 

     if(Validation.IsValidEmail(email, out errorMessage)) 
     { 
     ViewData.AddModelError("EmailAddress", "My Custom Error Message"); 

     //or 

     ViewData.AddModelError("EmailAddress", errorMessage); 
     } 
} 

これは、あなたが探しているが、それはあなたがまだそれをカスタマイズすることができることながら、再利用可能なコードを最大化する方法を考え出すに役立つかもしれない正確に何ではないかもしれません。

私はこのようにしていましたが、私は弾丸に敏感で、私の最近のアプリケーションはどこにでも標準エラーメッセージを使用していました。私のモチベーションは、ユーザーがますます短く単純な検証メッセージで快適になり、メッセージがサマリーではなくフォームフィールドにインラインで表示されている場合は、メッセージにこれにより、私のすべてのルール/メッセージをデータ注釈に入れることができ、それが扱うことが分かりました。

+0

ありがとうございます。Rob、Validation.IsValidEmailコードはドメインモデルの一部であり、ドメインモデルとコントローラの両方から呼び出すことができますか? –

+0

ええ - でも、あなたの現在のプロジェクトドメインだけに限定される必要はありません - これらのタイプのライブラリの多くは、コードを強固に結合することなくあなたの人生を簡単にする巧妙な方法特定のプロジェクト(可能な場合)。通常、初期設定は長くなりますが、投資収益率は通常高いです。 – Rob