Question

我有一个相当大的数据库，大约有80个左右的表。所以我决定将表分成有界上下文，而不是在一个大的edmx文件中包含所有80个表。

所以我有像销售，客户等有限的背景。

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

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

Answer 1

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

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

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

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

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

所以，无论如何都要使用有界上下文。这可以针对 SAME数据存储。并回答问题，因为“是的，相同的表（ DbSet）可以出现在许多情况下。

Answer 2

这种方法存在一些潜在的问题（IMO）：

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

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

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

如果您沿着分割数据的路线走下去，则需要保持分割。

虽然来自各个BC的数据可能都在同一个商店中，但您应该想到您的数据，就像每个BC都有自己的数据库一样。有时候我有一个项目，在不同的文件夹/命名空间（这里是.NET）中有各种各样的问题（某些层）。应该可以随心所欲地将这些问题分解成单独的组件。所以他们不应该太紧密耦合。您尝试拆分的数据结构也是如此。实质上，您应该能够将相关的BC数据拆分到单独的数据库中。在BC中获取数据的机制是另一回事，我想如果无法解决这个问题，您可能会发现它很难实现。

虽然我不认为从数据方面识别BC可能是最好的想法，但它肯定是朝着正确方向迈出的一步：）

Answer 3

如果您希望能够使用导航属性（Sale.Customer）从Sales实体访问Customer实体，则需要将其添加到sales edmx。

将所有表放在一个edmx中并不是一件坏事，只要你创建它，将它用于你想要的动作，然后处理它，对象图就不会得到那么大。

或者，如果你想保留有界的上下文，你可以在你需要的时候有一个存储库或者用ID来获取它。

var customer = customerContext.GetCustomerById(sale.CustomerId);

我是否在多个实体框架有界上下文中添加了相同的表

3 个答案: