リポジトリ/サービスのパターンとデータの一貫性

Question

リポジトリとサービスのパターンを使用するアプリケーションでは、サービスレイヤが常に呼び出され、リポジトリは直接呼び出されないことを確認するにはどうすればよいですか？

例：それはサービスのexistanceを知らないので、プログラマは、時々そのように単純ではありません（直接リポジトリを呼び出すことが

• ：

  class OrderRepository 
  { 
      void CreateOrder(Order o) 
      ... 
  } 
  
  class OrderService 
  { 
      void CreateOrder(Order o) 
      { 
       //make some business logic tests 
       ... 
  
       //call repository 
       _orderRepository.CreateOrder(o); 
      } 
  } 
  

  私は二つの問題を参照してくださいこの例のように（1つのサービス=同じメソッド名を持つ1つのリポジトリ）、いくつかのアプリケーションの文書化が不十分である、または急いでいる人が、対応するサービスが存在する（間違っている）かどうかを忘れる可能性があります。

• 全く異なる：長い時間前に、誰かがビューを作成し+注文リポジトリを直接使用するコントローラを作成しました。当時、ビジネスロジックのチェックや追加の操作を行う必要はなく、オーダーリポジトリのみが存在していました（それが必要ないため）。後で注文を作成するときに追加の操作が必要になる場合は、サービスが作成されます。問題は、古いリポジトリの呼び出しを行うすべてのコントローラを変更する必要があることです。レポジトリの原則/アイデア（とレイヤー内のコードの分離）は、部品を互いに独立させるものではないのですか？

Answer 1

すべてのリポジトリとサービスがそれぞれ独自のプロジェクト（ex。 RepositoriesおよびServices。

Repositoriesを参照する必要がある唯一のプロジェクトはServicesです。このようにして、他のプロジェクトはリポジトリにアクセスできなくなります。もちろん、開発者がリポジトリプロジェクトをコントローラプロジェクトに組み込むのをやめさせることはできませんが、この時点で、最初の場所に含まれていなかった理由を尋ねられます。

Answer 2

Static analysisこの点でツールが役立ちます。

nDependは、ビルドプロセスに組み込まれ、そのような状態（リポジトリクラスを直接呼び出す非サービスクラス）でエラーが発生する商用ツールです。