私はリポジトリ パターンとサービス レイヤーの役割について多くのことを読んできましたが、2 つの違いをよく認識しています (と思います)。しかし、単純な問題で、しばらく頭を悩ませています。
データアクセスレイヤーがどのようにデータにアクセスするかをよく知っています...データにアクセスするため、典型的なリポジトリには挿入、更新、削除、保存などのメソッド(基本的なCRUDメソッド)があります。サービス層には、すべてのビジネス要素、検証、電子メールの送信、およびすべてのジャズが含まれています。私が読んだことの1つは、このセットアップは価値を追加しないため、サービス層はリポジトリメソッドを繰り返すべきではないということでした.
しかし、私の問題は「追加」メソッドにあります。たとえば、サプライヤ クラスがあり、特定のサプライヤをサプライヤ リストに追加したいとします。ユーザーが UI (MVC Web アプリ) を介してサプライヤー情報を入力すると、Create
コントローラー メソッドが呼び出されます。
このサプライヤを維持するために、コントローラは何を処理する必要がありますか?
- リポジトリを直接
- サービス層
純粋なリポジトリの実装はエンティティを永続化する以外に何もしないため、検証やビジネス ルールがある場合は、明らかにサービス レイヤーを使用する必要があります。しかし、コントローラーがリポジトリを直接処理する必要がない場合はどうなりますか? これは、アーキテクチャの層状の性質を壊しているかのように私には思えます。コントローラーはサービス レイヤーをスキップし、永続レイヤーと通信しています。
安全な側にいて、サービスレイヤーを使用したいとしましょう(サプライヤーとの取引に関連する検証やその他のものがある可能性があるため)。私は次のようになります:
- AddSupplier メソッド
- UpdateSupplier メソッド
- DeleteSupplier メソッド
これは、サービス層とデータ アクセス層との 1 対 1 のメソッド マッピングがあるため、最初から望んでいなかったことです。
私の質問は次のとおりです: (Add | Update | Delete)Supplier メソッドはどこに行くべきですか?
また、サービス層をバイパスして、コントローラから直接リポジトリ層と通信しても問題ありませんか?