質問: configuration; } public IConfiguration Configuration { get; } // This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices(IServiceCollection services) { services.AddMvc(); Project.WebApi.Module.ConfigureServices(services); services.AddAutoMapper(); } } ``` Project.WebAPI.Module.cs ``` public class Module { public static void ConfigureServices(IServiceCollection services) { services.AddSingleton(); services.AddSingleton(); } } ``` サービスとリポジトリは現時点では単なるスタブです。 もう一度、私が避けたいのは、Project.WebAPI.Module.csクラスのservices.AddDbContextを呼び出さなければならないということです。 私が欲しいのは、私のWebAPIでハードコピーせずにProject.Repository.EFプロジェクトにDbContextを登録することです。 これも可能ですか?
回答: さて、私はあなたに少し明確にしましょう。 Repositoryパターンは、CRUD操作を行う単なるデータアクセスレイヤーではありませんが、私はあなたの問題を理解するのに役立つように私の答えを制限しようとします。 (以下の答えは、リポジトリを使用する必要がある場合にのみ関連します) まず、あなたのプロジェクトの名前をちょっと話しましょう。プロジェクト`Project.Repository.Contracts`名前に変更する必要があります`Project.Repository.DTOs`それをより明確にします。このプロジェクトには、DataContextがdbを生成してすべての操作を処理するために使用するデータ転送オブジェクトが含まれています。 `Project.Service.Contracts`名前を`Project.Domain`に変更すると、ビジネスロジック関連のすべてのモデルが作成されます。 Automapperは、dtosからドメインオブジェクトへの双方向マッピングを行うために使用されます。逆もまた同様です。 今度は`Project.Repository.EF`プロジェクトを2つの異なるプロジェクトに分割する必要があります。リポジトリはデータコンテキストについて知っておく必要があります。 EFはリポジトリについて知る必要はありません。 だから、から`Project.Repository.EF`プロジェクト、あなたが作成されます`Project.Data`と`Project.Repository`あなたの移行やデータコンテキスト自体をしている`Data`リポジトリがしている間プロジェクト`Repository`参照するプロジェクト`Data`のプロジェクトを。 今すぐデータプロジェクトは、スタートアップクラスで使用するためにAPIプロジェクトで参照することができ、サービスがリポジトリプロジェクト(およびサービスについてのWebプロジェクトのみ)についてのみ知っている限り、うまくいくはずです。 私はまた、この`Project.WebApi.Module.ConfigureServices(services);`ような静的呼び出しの代わりに、 `Data`プロジェクトで拡張メソッドを作成し`Project.WebApi.Module.ConfigureServices(services);` 。清潔です。 また、依存関係の間で共有プロジェクト内にStartupクラスを作成し、ホストを開始するプロジェクトのこの単一プロジェクトを参照することもできます。 DbContext、サービス、およびリポジトリの両方をIoCで何らかの形で設定する必要があることに注意してください。私のcuppaは、アセンブリマーカを作成し、これらの依存関係をスキャンするためにScrutorを使用することです 。 編集:カミーロが提案したように、Entity Frameworkコアにはリポジトリパターンはまったく必要ありません。 EF Coreはインターフェイスに基づいているため、それらの周りに独自のクラスを実装できます。 EFの上にリポジトリが必要な主な理由は嘲笑でした。これはもはや必要ではありません: 1. EFコアに内蔵されたメモリデータベース 2. インターフェイスに基づいているので、それらの周りに独自のクラスを実装できます