实体框架，预测和关系（哦，我的？）

Question

所以，我正在开发新软件，但我别无选择，只能将数据库整合到一起。我想在有意义的地方使用实体框架。

这是我的困境：

• 由于表格很宽，我无法改变这一点，我可能会大量使用投影来限制我查询的数据集的宽度。
• 我确实想在有意义的地方使用导航属性
• 从我看到的情况来看，很多人都使用了一个模型，其中整个项目都有一个DbContext类。

所以，

我正在权衡这些职业和缺点，我想知道既定的最佳实践可能是什么：

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

思想？

Answer 1

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

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

如果您正如上所述，那么我认为使用多个DbContexts不会给您带来任何好处。感谢。