中央データベースを持つシステムを構築しています。複数のアプリケーションがデータベース上で実行されます。そのため、複数のエンティティ フレームワーク ダイアグラムとセットアップを維持する必要はなく、データベースを使用するすべてのソリューションで共有される 1 つの専用アセンブリにすべてのエンティティ フレームワーク クラスを配置します。これまでのところ、これはかなりうまく機能しています。
現時点では、エンティティ フレームワークを使用して派生 DbContext を生成しました。
ただし、特定の状況では、オブジェクト コンテキストを使用した方が、達成しようとしていたことにより便利であることがわかりました。1 つの例は、参照エンティティの非常に単純な (キー -> 値) キャッシュ ソリューションです。「参照エンティティ」という名前を使用して、文字列値またはルックアップを提供するよりも少し多くの機能を提供するエンティティを説明しています。そのような状況では、エンティティ オブジェクトを別の DbContext に単純に追加することはできず、必要に応じてアタッチする必要があるため、DbContext からのエンティティ オブジェクトのキャッシュは面倒です。(これは私の頭のてっぺんの例なので、穴をあけてもあまり気にしないでください!)。
したがって、共有アセンブリで DbContext API と ObjectContext API の両方を提供する価値があると考えています。そうすれば、アセンブリのユーザーは、より便利になると判断したものを使用できます。明らかに、クラス名の競合を避けるために、それらを 2 つの非常に別個の名前空間に分割する必要がありますが、Company.Tech.Database.DBContext 名前空間と Company.Tech.Database.ObjectContext を使用することは問題ないと思います。
これは悪い考えだと思う人はいますか？良いアイデア？私の理解では、DbContext は新しいですが、必ずしも ObjectContext よりも「優れている」とは限らず、より単純と見なされる可能性のある別の API を提供するだけですが、それはユースケースに依存していませんか? その場合、両方の API を提供することは良いことではないでしょうか?