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

Question

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

目前，我已经使用实体框架来生成派生的DbContext。

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

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

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

Answer 1

你不能严格说出一个好主意或坏主意，因为没有这样的事情，这完全取决于你的情况。但我可以给你一个建议，你看到DbContext在其中包装了一个ObjectContext，它调用该ObjectContext上的方法来完成它的工作，所以不管怎样，它提供了ObjectContext的简化版本。当然，这意味着您仍然可以访问包含的ObjectContext实例，例如var ctx = ((IObjectContextAdapter)db).ObjectContext;，其中db是您的DbContext子类，因此不是提供两个可能会混淆客户端并需要更多维护的不同API，您可以增强DbContext子类具有性能所需的其他方法，而这些其他方法可以利用ObjectContext。这样，您将拥有更少的代码来维护和统一的API。