0

所以，我正在开发新软件，但我别无选择，只能对数据库进行改造。我想在有意义的地方使用实体框架。

这是我的困境：

  • 由于表格非常宽，而且我无法更改这一点，我可能会大量使用投影来限制我查询的数据集的宽度。
  • 我确实想在有意义的地方使用导航属性
  • 据我所见，很多人使用一个模型，其中整个项目只有一个 DbContext 类。

所以，

我正在权衡这些利弊，我想知道已建立的最佳实践可能是什么：

  • 使用 1 个 DbContext。
    • 这里可能有很多“污染”，在 1 个上下文类中存在大量数据投影。这听起来可能会成为维护的噩梦。
  • 根本不要让我的预测数据库集 - 只需让它们成为普通的旧对象并选择 new MyProject {..} 进入它们。
    • 这提供了将我的投影保存在特定于模块的程序集和命名空间中的好处，但现在我没有导航/延迟加载/等。
  • 作恶？？并使用多个 DbContexts？
    • 我不太确定这里的维护故事是什么样的，但我有点开始朝这个方向倾斜。我最大的问题是感觉就像我在逆流而上——似乎没有多少人这样做，但对于一个大型系统来说，它似乎是最好的选择。

想法？

4

1 回答 1

0

我认为您必须使用 POCO 或 DTO 在不同应用程序层之间进行数据传输。使用 ViewModel 向 View 发送数据。

考虑使用存储库模式和 UoW 在这种情况下拥有更好和高效的架构。将导航属性的使用限制到存储库，否则它们会在跨层传输这些属性时使实体变得沉重（使用 POCO 或 DTO）。

如果您按照上述方式进行操作，那么我认为使用多个 DbContexts 不会给您带来任何好处。谢谢。

于 2013-07-09T03:14:41.520 回答