リポジトリを使用する場合、ASP.NET MVCのビジネスロジックに最適な場所は何ですか？

Question

ASP.NET MVCプロジェクトでデータベースのリポジトリを実装する場合、ビジネスロジックを配置するのは正しいですか、コントローラクラスにロジックを配置する方がよいでしょうか？あるいは、データを操作するために追加のサービスとヘルパークラスを使用しますか？

Answer 1

最終的には、独自のレイヤー（「モデル」レイヤーの一部として）以外にビジネスロジックにとって完璧な場所はありません。多くの場合、別の実装で取り除くことができますが、すべてのケースでトレードオフがあります。

ビジネスロジックの別のレイヤーを作成することとのトレードオフは、実際にコードをカプセル化する必要があることです。あまりにも積極的であれば、エンティティとドメインモデルの間に重複が生じることもあります（DBのリレーショナルセマンティクスがすでにあなたのbuinessロジックを処理している場合）。それは変更する可能性が最も高い部分があるとして

ビュー

ビューは、あなたのアプリの中で最も脆い部分です。

さまざまなビューの状態遷移をすべてサポートする必要があるため、ビューでビジネスロジックを正しく取得することも非常に難しいです。

非常によくあなただけのこれをしない、これらの日を知られている:)

リポジトリ

ここでの問題は、抽象化のメンテナンスと純度の一つです。これを違反すると、人々を混乱させる可能性があり、アプリを維持しにくくする可能性があります。

the P of EAA article on the Repository patternから：Aリポジトリドメインとデータ・マッピング層の間に介在する

、メモリ内のドメインオブジェクトのコレクション

リポジトリのように作用すると、あなたのデータストレージを提供する抽象化ですコレクションはドメインオブジェクトを保持します。

ドメインロジックは存在しません。代わりに、ドメインオブジェクトに存在する必要があります（ビジネスロジックはドメインです）。

（リポジトリを二重にしてドメインロジックを検証するために）SRP（Single Responsibility Principle）に違反し、コードの匂いになります。

ドメインオブジェクトのコレクション（オブジェクトのコレクション内の依存性、サイズ制限など）を検証するために、ドメインオブジェクトのコレクションで動作する上位レベルのドメインオブジェクトを持つことができます。彼らは引き続きあなたのリポジトリをカバーしてドメインオブジェクトの最終的な保存/取得を行いますので、二重課税はしません（SRPに違反しません）。

コントローラ

コントローラは、ビジネスロジックを置くのに良い場所ではありません。コントローラの仕事は、コントローラとモデルを仲介することです。

モデルはドメインであり、ドメインはビジネスロジックです。

エンティティ

あなたはエンティティにドメインデータを置くことを検討してください。

エンティティが接続されている場合はナビゲーションプロパティにアクセスする際に注意しなければなりません。迷惑なDBクエリや例外が発生する可能性があります（コンテキストが破棄されているかどうかによって異なります）。それらを切り離すことも問題です。コンテキストからオブジェクトを外した後にオブジェクトを明示的に再接続しない限り、オブジェクトグラフは破壊されます。

別のドメインモデルクラスを作成する場合は、エンティティをDTOsとして扱うことを検討することがあります。

編集：IValidatableObjectインタフェース：IValidatableObject

私はあなたがチェックアウトすることをお勧めしますエンティティフレームワーク4.1の機能について今分かりました。

エンティティを部分クラスにし、部分クラスでこのインターフェイスを実装できます。エンティティフレームワークでは、保存時にValidateが呼び出され、Validateに電話することができます。

これは、ドメインモデルから永続モデルを分割することを避けるのに役立ちます。

この記事を参照してください：http://msdn.microsoft.com/en-us/data/gg193959

サイドノート：あなたはそれについて考えている場合、ビュー/ビューモデル

を、私はあなたが戻ってビューにエンティティを渡す誘惑を避けることをお勧めします。多くの場合（ビューステートを保存するためのJavaScriptのシリアライゼーションなど）、別のケースで意図しないDBクエリが発生します。代わりに単純な型（文字列、int、リスト、ハッシュセット、辞書など）を渡すか、ビューモデルクラスを作成してビューに渡します。

Answer 2

ドメインモデルにビジネスロジックが存在する必要があります。

この回答を確認してください。

ASP.NET MVC - Should business logic exist in controllers?

Answer 3

コントローラに対応するサービスクラスを追加することができるリポジトリにモデルを渡すサービス層を追加します。たとえば、UserControllerとUser Modelを使用する場合、User ModelにUser Modelを渡すことができます。

ここで、サービスレイヤは、リポジトリとコントローラの間のブリッジとして機能し、コントローラとリポジトリの分離が十分に確立されます。

Answer 4

私の意見では、ビジネスロジックに依存します。ロジックは、入力ルールと入力ルールの検証に基づいていますかもしそうなら、それはモデル上にあるのが最善かもしれません。しかし、ワークフローに基づくビジネスルールであれば、ユーザーがオプションAを選択した後、オプションBを選択した場合とは異なるページ/フォームにリダイレクトされるなど、コントローラ内にある必要があるかもしれません。ビジネスルールでデータの永続性を処理する必要がある場合は、リポジトリに移動する必要があるかもしれません（私にそれを置くことは奇妙に思われます）。これについては数多くの議論がありますが、最終的な製品が実装に基づいてどのようにメンテナンス可能で柔軟性があるかについては、お客様またはチームの視点に基づいています。

Answer 5

私は上記に同意しますが、コントローラーは適切なビューを返すだけのビジネスロジックを担当すべきではありません。私はサービスレイヤーを使用してビジネスロジックを提供し、モデル作成を見て、コントローラがサービスから返されたモデルを単にビューに渡すようにします。

また、私のビューモデルが単純なDTOであることを保証します。サービスはプロパティを適切に設定する方法を知っています。