私は最近、無知と時間の不足から、いくつかのプロジェクトのドメイン モデル (POCO エンティティ クラス) を 1 つの 'DataModel' プロジェクトにマージしました。さまざまなクライアント プロジェクトから DbSet インスタンスを追加できる DbContext 拡張機能など、一般的な処理を行うことが理想的だと思いました。
私は、リポジトリ機能が DbSet クラスによって完全に満たされていると主張している著者と通常は同じサークルで、そのようなことについての言及を読みました-そして私は心から同意します.
1 つのプロジェクトに存在できる一般的な DbContext を構築するためのアドバイスを誰でも提供できますか?他のプロジェクトはすべて、共有 DbContext に登録されたドメイン モデル (ドメイン エンティティのセット) を持つことができます。リポジトリ？
1 つのプロジェクトに存在できる一般的な DbContext を構築し、他のプロジェクトはすべてドメイン モデル (ドメイン エンティティのセット) を登録できます。
興味深いアイデアですが、それによって何が得られるかはわかりません。
db.Customer1 つには、単に入力する(または同様の)ことは決してできません。全然知っているかどうかわからないgenericdb.Set<Customer>()、いつものはずです。（登録されていない可能性があります）。genericdbCustomer
では、この登録はどのように行えばよいのでしょうか。コンテキストでクラスをデータベース モデルにマップするには、次の 2 つの方法があります。
DbSet派生クラスでプロパティを作成し、DbContextテーブルと列の名前、複数形などに関するコード ファーストの既定の規則に依存します。最初のオプションはジェネリック コンテキスト クラスの目的に反するため、ドメイン内の各クラスにEntityTypeConfiguration<T>s を指定してドメイン クラスを登録する必要があります。(ちなみに、これはコンテキストのコンストラクターで行う必要があります。)
さらなる意味は、どのクラスのグループが一緒に属しているかを認識し、構成の一貫したリストを提供できるコンポーネント/サービスがどこかで必要になるということです。したがって、すぐに使用できる組織化の原則として専用のコンテキストを使用する代わりに、独自のオーガナイザーを作成する必要があります。
しかし、最初に戻ります。プロジェクトに以前から存在していたコンテキストを提供する DbContext ファクトリを含む DAL を作成できませんでしたか? この方法で専用の DbContext クラスを複製する必要はありません。