1

ビジネスロジックをコントローラーから遠ざけるのは常識です。ここで説明するように、リポジトリ パターンを使用して、データベース アクセス ロジックをリポジトリに配置することも常識です:リポジトリ パターン

ただし、リポジトリ パターンでは、非常に単純な低レベルのデータベース操作 (挿入、削除、更新、選択) のみが指定されています。検証ロジックも除外することをお勧めします。ほとんどの検証はモデル オブジェクト自体の内部に配置できるため、これは問題ではありません。問題は、ある種の相互検証、つまり、同じモデル オブジェクトの複数のインスタンスを調べる必要がある検証を行う必要がある場合に発生します (たとえば、同じオブジェクトのすべてのインスタンスで名前が一意であることを確認するなど)。 ) またはさらに悪いことに、検証ロジックが異なるタイプの 2 つ以上のオブジェクトをチェックする必要がある場合。この場合、非常に大きな穴があります。ビジネス ロジックをコントローラーに配置したり、リポジトリに配置したり、オブジェクト モデル自体に配置したりすることはできません (ロジックはオブジェクトのプロパティだけにバインドされているわけではないため)。このロジックはどこにあるべきですか？この種の要件に最適な設計パターンは何ですか?

4

2 に答える 2

0

ここで説明されているように、サービス層を作成できます: http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validating-with-a-service-layer-cs

于 2012-10-12T19:51:22.483 に答える
0

ここでの問題は、UI がビジネス上の懸念に基づいて検証を行う必要があることです。

これを達成する方法は、検証をビジネス層に抽象化することです。ビジネスレイヤーには次のようなメソッドがValidateUserIsUnique()あり、UI がこのレイヤーを呼び出して結果を受け取り、それが検証に使用されます。

特に、クライアント側の検証の場合、MVC は を提供しますがRemoteValidationAttribute、これはクライアント側の検証のみを行います。サーバー上で同じ (または同様の) 関数を呼び出すサーバー側の検証も行う必要があります。

于 2012-10-12T21:17:37.953 に答える