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

リポジトリパターンを使用する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（））でrepoインターフェースを呼び出します

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

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

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

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

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

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

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

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

コントローラについて少し説明します。MVCは、メインフレームとテキストスクリーンアプリがあったときから遡ります。モデルはメインフレーム上のデータであり、ビューは端末画面であり、コントローラーはキーボードでした（＃を押してモデルを操作します）。

最近はマウスを使用し、（アプリケーションを制御するための）ボタンがビューに表示されるようになりました。