0

中央データベースを持つシステムを構築しています。複数のアプリケーションがデータベース上で実行されます。そのため、複数のエンティティ フレームワーク ダイアグラムとセットアップを維持する必要はなく、データベースを使用するすべてのソリューションで共有される 1 つの専用アセンブリにすべてのエンティティ フレームワーク クラスを配置します。これまでのところ、これはかなりうまく機能しています。

現時点では、エンティティ フレームワークを使用して派生 DbContext を生成しました。

ただし、特定の状況では、オブジェクト コンテキストを使用した方が、達成しようとしていたことにより便利であることがわかりました。1 つの例は、参照エンティティの非常に単純な (キー -> 値) キャッシュ ソリューションです。「参照エンティティ」という名前を使用して、文字列値またはルックアップを提供するよりも少し多くの機能を提供するエンティティを説明しています。そのような状況では、エンティティ オブジェクトを別の DbContext に単純に追加することはできず、必要に応じてアタッチする必要があるため、DbContext からのエンティティ オブジェクトのキャッシュは面倒です。(これは私の頭のてっぺんの例なので、穴をあけてもあまり気にしないでください!)。

したがって、共有アセンブリで DbContext API と ObjectContext API の両方を提供する価値があると考えています。そうすれば、アセンブリのユーザーは、より便利になると判断したものを使用できます。明らかに、クラス名の競合を避けるために、それらを 2 つの非常に別個の名前空間に分割する必要がありますが、Company.Tech.Database.DBContext 名前空間と Company.Tech.Database.ObjectContext を使用することは問題ないと思います。

これは悪い考えだと思う人はいますか?良いアイデア?私の理解では、DbContext は新しいですが、必ずしも ObjectContext よりも「優れている」とは限らず、より単純と見なされる可能性のある別の API を提供するだけですが、それはユースケースに依存していませんか? その場合、両方の API を提供することは良いことではないでしょうか?

4

1 に答える 1

2

良いアイデアか悪いアイデアかを厳密に言うことはできません。そのようなものは存在しないためです。それは完全に状況に依存します。しかし、私はあなたに提案を与えることができます.DbContextはその中にObjectContextをラップし、そのObjectContextのメソッドを呼び出してその仕事をするので、何らかの形でObjectContextの簡略化されたバージョンを提供します. もちろん、これは、DbContext サブクラスが存在するこのようなラップされた ObjectContext インスタンスに引き続きアクセスできることを意味しますvar ctx = ((IObjectContextAdapter)db).ObjectContext;dbしたがって、クライアントを混乱させ、より多くのメンテナンスを必要とする可能性のある 2 つの異なる API を提供する代わりに、パフォーマンスに必要な追加のメソッドで DbContext サブクラスを拡張できます。これらの追加のメソッドは ObjectContext を活用できます。これにより、維持するコードが少なくなり、API が統一されます。

于 2013-06-24T21:55:41.497 に答える