コントローラからサービスとリポジトリ層を呼び出す
チームに質問が来ました。皆さんにお聞きします。私たちのアプリケーションは、サービス層でMVCを使用しています。ただし、サービスレイヤーが何もせずにリポジトリを呼び出す場合もあります。
私たちの質問は次のとおりです。この場合、リポジトリをコントローラから直接呼び出しても問題ありませんか？たとえば、ビジネスロジックがあるときにサービスを呼び出すコントローラーがあり、サービスがリポジトリを呼び出すとします。しかし、直接選択のみで使用するロジックがない場合、コントローラーはリポジトリーを呼び出します。
Ifリポジトリレイヤーが適切に抽象化されている（たとえば、サービスレイヤーとコントローラーがインターフェイス経由でのみリポジトリにアクセスできる）：
- コントローラーがリポジトリーに直接アクセスすると、不要なレベルの抽象化が削除されるため、コードのその部分が単純化されますが、
- 次に、コントローラーをサービスレイヤーとリポジトリレイヤーの両方に結合します。これにより、複雑さが増す可能性があります。
- 将来その時点でビジネスロジックを追加する必要があり、コードのその部分を「再配管」する必要がある場合、メンテナンスの問題が発生する可能性がありますが、
- YAGNI（「あなたはそれを必要としない」）の原則がここで作用するため、このような潜在的な将来の問題が今デザインに影響を与えることを許可することはほとんどありません。
結局のところ、私はすべてをサービスレイヤーに通すことに固執します。しかし、それは純粋な意見です。リポジトリへの直接アクセスも同様に有効です。
リポジトリレイヤーが適切に抽象化されていない場合（つまり、サービスレイヤーが具体的なリポジトリ/データベースクラスを直接処理する場合）、次のようになります。
- 修理する！
- 修正するまでは、コントローラをリポジトリの近くに移動しないでください。このパスは、地獄のテストにつながるためです。
一貫性を保ち、パススルーとしても常にサービス層を呼び出すことをお勧めします。一貫性は、興味のないコードを数行保存するよりも重要です。これにより、将来の変更に対応するための潜在的なビジネスロジックを追加でき、サービスレイヤーに空のメソッドが多数ある場合に、ビジネスロジックを必要以上に分離していないことを示すシグナルとして役立ちます。
プロジェクトを維持できることの大部分は、予期しない動作をし、同じパターンに従わない領域がほとんどないか、まったくないことです。
リポジトリクラスに必要な依存関係は、コントローラークラスでは必要ありません。依存関係がそこにあることを気にしない場合は、パススルーコールをスキップして、リポジトリに直接進むことができると思います。
要約すると、コントローラーがリポジトリーに依存するようになります。
私は、リポジトリが実際のデータストアより上の抽象概念であり、データベースやファイルシステム、または何を持っているかを直接呼び出さないことを前提にしています。