.net 实体框架：在共享程序集中提供DbContext和ObjectContext API

我一直在构建一个有中央数据库的系统。多个应用程序将在数据库上运行。因此，我不必维护多个实体框架图和设置，而是将所有实体框架类放入一个专用程序集中，该程序集将在使用数据库的所有解决方案中共享。到目前为止，这一切都很顺利

目前，我已经使用实体框架生成了一个派生的DbContext

然而，我发现在某些情况下，拥有一个对象上下文对于我想要完成的事情会更方便。一个例子是一个非常简单的（key->value）引用实体缓存解决方案。我使用“引用实体”这个名称来描述实体，这些实体的功能仅限于提供字符串值或查找。在这种情况下，缓存DbContext中的实体对象很麻烦，因为您不能简单地将它们添加到另一个DbContext中——如果需要，您必须附加它。（这是我头顶的一个例子，所以不要太担心在上面挖洞！）

因此，我认为在共享程序集中同时提供DbContext API和ObjectContext API是值得的。这样，程序集的用户就可以使用他们认为更方便的方法。显然，我必须将它们分成两个非常独立的名称空间，以避免类命名冲突，但我认为，拥有Company.Tech.Database.DBContext名称空间和Company.Tech.Database.ObjectContext应该可以

---

有人认为这是个坏主意吗？好主意？我的理解是，虽然DbContext较新，但它不一定比ObjectContext“更好”，它只是提供了一个不同的API，可能会被认为更简单，但这不取决于用例吗？在这种情况下，提供两种API不是一件好事吗？

你不能严格地说是好主意还是坏主意，因为没有这样的事情，这完全取决于你的情况。但我可以给你们一个建议，你们看DbContext在它里面包装了一个ObjectContext，它调用那个ObjectContext上的方法来完成它的工作，所以它以某种方式提供了ObjectContext的简化版本。当然，这意味着您仍然可以像下面这样访问包装的ObjectContext实例

var ctx=（（IObjectContextAdapter）db）

其中

db

是DbContext子类，因此，您可以使用性能所需的其他方法增强DbContext子类，而不是提供两个可能会混淆客户端和需要更多维护的不同API，这些附加方法可以利用ObjectContext。这样，您将有更少的代码需要维护，并且有一个统一的API

公正的评论。我想我的问题措辞不是特别好；我更想知道我这样做是否会违反任何最佳实践。@dark_perfect，通常不会，你唯一违反的实践是提供了两种不同的API，正如我所说的，这会导致更多的维护和混淆用户，他们会想，我什么时候应该使用什么？我不知道还有什么副作用。