0

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

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

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

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

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

4

1 回答 1

2

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

于 2013-06-24T21:55:41.497 回答