实体框架DataContexts

Question

我正在努力设计并试图找出接近它的最佳方式。

我们有很多表，在当前的LinqToSql实现中，我们的DBML大小很多，非常笨拙。如果可以的话，我想避免重现这种情况。我们根据每个用户决定连接字符串，因此很难为不同的表组创建单独的dbmls。

我开始使用Entity Framework，虽然我们不需要Code First元素，但我喜欢轻量级代码而不需要所有代码，我们不需要可视化映射，所以我在考虑生成所有表的代码文件，然后将它们作为DbSets添加到DataContext中。

这让我想到了这里的最佳实践，我想问这个问题;

为要使用的每组表创建DataContext是否明智。即我将要有一个模块，它将负责从5个表中收集数据，它不需要数据库中的每个表，只需5.我是否创建了包含这5个表的DbContext。如果我将来需要更多，我可以添加它们，但它是轻量级的。

Answer 1

你当然可以这样做。您只需将表添加到edmx模型中，就像在Linq2SQL中一样，只需添加您需要的5个表，您就可以节省其他未跟踪表的实体跟踪开销。实体框架很好地添加了Linq2SQL没有的双向导航属性。我建议使用EF而不是Linq2SQL。

Answer 2

大型DBML模型没有任何本质上的坏处，EF中的性能影响应该可以忽略不计。

另一方面，在我看来，降低复杂性也适用于实体框架 - 如果您的代码只需要数据库中的5个表，那么创建一个单独的上下文，只有这5个表的实体。通过将完全独立的表分解为单独的上下文，您可以清楚地表达这种分离 - 这些表与数据库中的其他表没有依赖关系，也没有从代码到不相关实体的依赖关系 - 如果是这种情况我认为（并且可能还有其他意见）这是要走的路。

但是请记住，如果你需要在另一个上下文中使用其中一些表，你也必须将相应的实体放入该上下文中 - 很难理解相同的表存在于多个上下文中甚至是上下文之间的交叉依赖关系。这应该避免，因为它增加了复杂性。

Answer 3

虽然您可能为每个表组分配一个单独的上下文，但如果您的模型很大，或者您的域不同，您可能需要考虑添加一个抽象层。通过这个，我的意思是有一个包含整个模型的上下文，然后在repository pattern的行中添加一些内容。 This是一篇关于用EF实现这一目标的好文章。

通过这样做，您基本上可以实现两个目标：抽象出您的数据层，从而释放实施问题;并且，允许您的开发人员只使用他们需要的实体，可能按aggregate root分组。

我想说清楚一件事。我不一定建议您使用特定的端到端架构（即DDD）。我在这里尝试做的是建议一些模式，这些模式可以让你灵活地让你犯错误（优雅地失败），同时仍然在你的项目上取得进步。