asp.net-mvc - リポジトリパターンは、リモートサービスを呼び出すだけのASP.NetWebAPIプロジェクトに有効ですか？

Question

ASP.NetWebAPIを使用してサービスファサードに似たものを開発しています。目的は、バックエンドシステムとモバイルアプリケーションの間にRESTfulな中間層を作成することです。

これらのサービス操作内のコードには、データベースのデータにアクセスするロジックは含まれていません。つまり、EFフレームワーク、Linq to SQLなどです。代わりに、バックエンドシステムによって提供される別のリモートサービスのセットを呼び出すことによって、データが選択および更新されます。

サービス操作ごとに、ある種の単体テストを実装する必要があります。私がオンラインで訪れたほとんどすべてのWebAPIユニットテストチュートリアルには、Entity Frameworkを介したデータアクセスが含まれており、リポジトリクラスは単一のEFエンティティをラップするだけです。

したがって、私の場合

1. 前述のように、サービス操作内にデータアクセスロジックがない場合に単体テストを実行することは意味がありますか？

2. もしそうなら、リポジトリパターンは進むべき道ですか？可能であれば、リモートサービス呼び出しを介してデータにアクセスするMVCプロジェクトに対してテストする例をリンクしてください。

3. 統合テストと単体テストを混同していますか？

4. もしそうなら、私は統合テストに行き、単体テストを忘れるべきです。

前もって感謝します。

Answer 1

1. はい、まだレイヤーをテストする必要があり、そこでリポジトリ パターンが役立ちます。実際、サービス レイヤーはリポジトリ自体のように機能しているようです。ただし、サービスは、リモートサーバーを抽象化する独自のリポジトリを使用します。

2. 例にはリンクしません。検索できますが、物事は非常に単純です。それがmvc、モバイル、またはその他のものであるかどうかは関係ありません。リポジトリは、ストレージ関連のファサードとして機能します。この場合、リモート バックエンドです。これにはリモート サービスを呼び出すコードが含まれますが、アプリの残りの部分は抽象化、つまりリポジトリ インターフェイスを使用します。

3,4. IMO関連するテストがある限り、それらをどのように呼び出すかは問題ではありません

1 つ以上のリポジトリ インターフェイスを定義し、それらを API で使用するだけです。モックまたは偽のリポジトリを使用して API をテストします。それらは単体テストです。

その後、リモート サービスを処理する実際のリポジトリの実装を記述します。