web-dev-qa-db-ja.com

サービスレイヤーのあるリポジトリパターン-分離が多すぎますか？

リポジトリパターンを使用するMVCサイトがあります。 MVCスタイルを十分に使用しているようには思えないので、その一部を再構築する準備をしています。しかし、私もそれを実行したいので、フロントエンドが変更された場合は、交換しやすくなります。

これが私が現在持っているものです

モデル-一部のモデルには、エンティティ/クラスが直接含まれています。 （ログインモデルにはCustomerクラスが含まれます。これは、Customerテーブル/リポジトリクラスと直接相関しています）ビュー-ビューの一部にリポジトリクエリが含まれています-つまり

_customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name);

コントローラー-ここではそれほど大きな問題ではありません。コントローラーはいくつかのレポクエリを呼び出します。一部のコントローラーはいくつかのサービスを使用してレポを呼び出します-すなわち

_customerService.GetAllCustomers()

呼び出す

_customerRepo.Query().All();

ここに私の考えがあります：

1）モデルには、ビューに表示する必要があるデータのみを含める必要があります。 Customerテーブル/オブジェクトのすべてのプロパティがビューに表示されている場合でも、ビューがデータベースアーキテクチャまたはバックエンドオブジェクトについて何も認識しないように、それらを独自のモデル/クラスに書き直す必要があります。

2）ビューはモデルオブジェクトにのみアクセスする必要があります

3）（そして、これが私が取るべき道に苦労しているところです）

a）コントローラー（またはMVC側のどこか）は、repo/servicesから返されたオブジェクトデータを変換してモデルに変換するコードである必要があります。このコードをモデルコンストラクターに配置できると想定していますが、検証エラーがある場合に備えて、DIはデフォルトの空のコンストラクターを想定していることに気付きました

b）コントローラは、データを取得するための適切な名前のメソッドでレポインターフェースを呼び出します（つまり、_customerRepo.GetAllCustomers（）

c）コントローラはサービス層にのみアクセスします。サービスレイヤーは、リポジトリレイヤーと対話する唯一のものです。

モデル、コントローラー、サービス、リポジトリレイヤーを抽出しすぎていますか？サービスレイヤーはすべてリポジトリで実行できるため、オーバーヘッドが多すぎませんか？

オブジェクト/ビジネスエンティティをモデルに変換するための推奨されるアプローチは何ですか？

design-patternsarchitectureasp.net-mvcarchitectural-patterns
8
ganders

はい、ビジネスロジックがない場合、サービスレイヤーはオーバーヘッドになります。レイヤードアーキテクチャは、レイヤー（あなたの場合はサービス）があまり機能していないときのオーバーヘッドのように見えます。しかし、階層化されたアーキテクチャは、疎結合を提供します。これは、通常、将来の要件に適応するのに適しています。

リポジトリからモデルへのデータのコピーを除いて、サービスレイヤーで何もする必要がないことが保証できる場合は、デザインからサービスレイヤーを削除できます。ただし、アプリケーションが基本的なものであれば、パフォーマンスやその他の理由で別のレイヤーを追加することを心配する必要はありません。

個人的には、サービスレイヤーを維持し、（テクノロジによって異なります）汎用のDAO /リポジトリレイヤーを実装します。

8
Parvez

それはあなたの具体的なリポジトリに依存しますが、一般的に言えば、リポジトリの上にサービス層を追加します。

リポジトリの実装によっては、永続ストアに固有の場合があります。これにより、テストも簡単になり、古典的なレイヤードアーキテクチャではなく、六角形のアーキテクチャになります（これは利点だと考えています）。参照 https://blog.8thlight.com/uncle-bob/2012/08/ 13/the-clean-architecture.html 。

3
Kevin Wittek