0

私がやりたいことは、EF を操作して、共有データベースにアクセスするプラグインをサポートすることです。したがって、データベースには、メイン アプリケーションのすべてのテーブルと、各プラグインに必要なすべてのテーブルが含まれます。アプリケーションはプラグインのデータ構造について何も知らないため、それらの管理を担当することはできません。プラグインは単独で責任を負い、テーブル自体を作成します。ただし、プラグインはホスト アプリケーションとそのデータ構造を認識しているため、理想的には、それらを参照したり、それらから継承したりできる必要があります。これにより、拡張可能でありながら最適化されたパターンを実装できるデータベースが得られます。

EF では、これは、ホストに適した DbSets を含む HostContext に変換されます。各プラグインには、プラグインに必要な DbSet を含む HostContext から継承する PluginContext が必要だと思いました。PluginContext に含まれるエンティティ クラスは、HostContext エンティティを参照したり、それらのエンティティから継承したりでき、EF はテーブル マッピングと関係を解決できます。

私はEF6を使用しています。上記を試みて、PluginContext に含めた単一のエンティティをリストしようとすると、エンティティが存在しないことを訴える例外がスローされます。案の定、一致するテーブルは作成されていません。

私がやろうとしていることは EF によってサポートされていますか? もしそうなら、私は何を間違っていますか？

4

1 に答える 1

0

ここで述べたように: EF6 Empty Model target string ここでローワン・ミラーの例を使用してこの取り組みを開始しました: http://romiller.com/2013/02/15/extending-and-customizing-code-first-models-part-2- -2/

最終的に、いくつかの理由でそのアプローチを断念しました: 1) 動作させることができませんでした (正確な理由は思い出せませんが、この記事が書かれて以来の EF の違いに関連していると思われます)。 2) 手動で移行を作成する必要がありませんでした。

私が望んでいたように、HostContext から継承する PluginContexts になり、ホスト エンティティを参照したり、継承することさえできます。ただし、これには使用上の制限があります。

  1. 私のプラグイン ロジックは完全に自己完結型です。ホスト アプリケーションがプラグイン エンティティを操作または作成する必要はありません。したがって、ホスト エンティティの代わりにプラグイン エンティティをシステムに使用させようとしているわけではありません。特定のエンティティ サブクラスの構築が必要な場合は、そのためにプラグイン メソッドを提供する必要があり、継承階層が利用されます。

  2. 移行は、通常どおりプラグイン コンテキストでも構築できます。ただし、その移行には、ホスト コンテキストからの移行コードが簡単に含まれる場合があります。したがって、これらの指示を探して削除することを忘れないでください。これは通常、非常に簡単で、ゼロから同等のものを構築するよりもはるかに労力がかからないと思います。

  3. ホスト コンテキストに変更があった場合、これをすべてのプラグイン コンテキストに反映する必要があります。基本的に、これは、ホスト コンテキストの変更を反映するために新しい移行が作成されるたびに、その移行が空である可能性がある場合でも、プラグインごとに移行を作成する必要があることを意味します (実際にはそうではありません - ここで重要な部分は、モデルを更新することです継承されたホスト モデルのために変更されたプラグイン モデルを反映するための最新の MigrationHistory レコード)。

このアプローチは、社内プラグインを使用して社内アプリケーションを拡張するために使用されているため、Rowan のソリューションがおそらくより適している他のシナリオでは採用が容易ではない可能性があります。

于 2013-09-25T19:36:43.310 に答える