5

我有一个相当大的数据库，大约 80 个表左右。因此，我决定将表分隔为有界上下文，而不是将所有 80 个表放在 1 个大 edmx 文件中。

所以我有有限的上下文，比如销售、客户等。

我的客户 edmx 文件中有我的主要客户表。但是，我还需要从销售 edmx 上下文的客户表中访问某些字段，而不是全部，而是 1 或 2 个字段（例如，我只需要客户名称，而不是整个客户对象/表）。

我是否必须将整个客户表添加到销售 edmx 文件中？这种情况的最佳做法是什么？

4

3 回答 3

10

我喜欢 Julie Lerman 对这个话题的看法http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

我使用有界上下文来提高访问性能，因为即使使用生成的视图，使用较小的 dbcontext 时上下文的加载时间也会更快。简化访问模型是很好的额外。MS ef 网站上的性能考虑提示：http: //msdn.microsoft.com/en-us/data/hh949853

BC 还允许其他好处，例如限制访问以匹配业务问题。如果您尝试使用不仅 DBSet 出现在其中，而且您尝试更改模型视图的 db 上下文也会出现更大的问题。我认为最好在 EF 之外完成并映射。

我使用一个大的 SUPERSET 上下文来管理数据库创建/迁移。但不是日常访问。

较小的 DBcontexts 用于每天全天访问数据。

所以是的，一定要使用有界上下文。这可以针对SAME 数据存储。并以措辞“是的，同一张表（DbSet）可以出现在许多情况下”来回答这个问题。

于 2013-03-01T06:16:45.033 回答
6

这种方法（IMO）有几个潜在的问题：

EF 与任何 ORM 一样，属于持久性问题。因此，它不应该干扰您构建域模型的方式。您将所有实体都持久化在一个听起来像是一个持久性存储中的事实可能表明您的有界上下文重叠或不存在。

尝试转向更好的结构并不是一件坏事:) --- 然而，正如 Mark Oreta 所说，我可能不会为 EF 结构而烦恼。

您遇到的主要问题是由于尝试从您的域模型中读取而引起的。这似乎在系统中经常出现，这让事情变得相当困难。延迟加载正是这种情况的直接结果。理想情况下，当您阅读时，您应该使用可以访问针对阅读进行了优化的查询存储（可能是同一个数据库）的查询层。在您的示例中，您需要在销售域中使用非规范化的客户名称。没事儿。试图通过读取您的域模型然后尝试在另一个有界上下文中从域模型中提取数据来实现这一点是导致您痛苦的原因。

如果您沿着拆分数据的路线走，那么您将需要保持拆分。

尽管来自不同 BC 的数据可能都在同一个存储中，但您应该将数据视为每个 BC 都有自己的数据库。有时，我在不同的文件夹/命名空间（此处为 .NET）中有一个具有各种关注点（层到某些层）的项目。应该可以一时兴起将这些关注点拆分为单独的程序集。所以它们不应该耦合得太紧。您尝试拆分的此数据结构也是如此。您本质上应该能够将相关的 BC 数据拆分到单独的数据库中。跨 BC 获取数据的机制是另一回事，我想如果无法解决这个问题，您可能会觉得很难。

虽然我不认为从数据方面识别 BC 可能是最好的主意，但这肯定是朝着正确方向迈出的一步 :)

于 2013-03-01T04:39:47.697 回答
2

如果您希望能够使用导航属性从您的销售实体访问客户实体， ( Sale.Customer) 您需要将其添加到销售 edmx。

将所有表放在一个 edmx 中不一定是坏事，只要您创建它，将其用于您想要的操作，然后处理它，对象图就不会变得那么大。

或者，如果您想保留有界上下文，您可以有一个存储库或在您需要时通过 ID 获取它的东西。

var customer = customerContext.GetCustomerById(sale.CustomerId);
于 2013-03-01T03:37:35.327 回答