3

これがひどく主観的でないことを願っていますが、ビジネス ロジックの検証に関して言えば、2 つのパスがあり、間違いがない限り、ほとんど同じ結果が得られます。

最初のインスタンスでは、モデルはデータのダム コンテナーであり、2 番目のインスタンスでは、モデルはその有効な状態を認識しています。それ以上に、私が見逃している2つのニュアンスはありますか? 場合によっては、どちらか一方を使用する必要がありますか?

ありがとう、

クリス

4

2 に答える 2

3

私の意見では、Data Annotations またはFluent Validationを使用してモデル (InputModel) に基本的な検証 (必須フィールド、正規表現フィールド、比較フィールドなど) を保持し、サービス層でビジネス検証を行うことができます。Annotations は、ビジネスの検証よりも、画面の検証とサーバー側への入力を作成するためのものだと思います。ビジネスをサービス レイヤーで維持する場合は、ModelStateWrapper を作成して Asp.Net MVC と統合し、それをビューに表示することを忘れないでください。

ModelState ラッパーの samepl を見てみましょう。

public class ModelStateWrapper : IValidationDictionary
{
   private ModelStateDictionary _modelState;
   public ModelStateWrapper(ModelStateDictionary modelState)
   {
      _modelState = modelState;
   }

   #region IValidationDictionary Members

   public void AddError(string key, string errorMessage)
   {
      _modelState.AddModelError(key, errorMessage);
   }

   public bool IsValid
   {
      get { return _modelState.IsValid; }
   }

   #endregion
}
于 2012-11-05T15:47:14.997 に答える
1

それらは相互に排他的ではなく、「静的」ルールには属性を使用でき、「動的」ルールにはサービス層の検証 (一意性のチェックなど) を使用できます。

参照したチュートリアルを引用します。

このチュートリアルでは、検証ロジックをコントローラーから別のサービス レイヤーに移動する方法を学習します。

データ アノテーション属性で装飾されたモデルは、コントローラーの隣の Web プロジェクトにある必要はありません。サービスの隣のサービス レイヤーにあってもかまいません。つまり、すべての検証ロジックが 1 か所にあります。

于 2012-11-05T15:53:11.640 に答える