问是否在多实体框架绑定上下文中添加相同的表

EN

这种方法(IMO)有几个潜在问题：

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

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

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

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

尽管来自不同BC的数据可能都在同一个存储中，但您应该将您的数据视为每个BC都有自己的数据库。有时，我在不同的文件夹/名称空间(这里是.NET)中有一个具有各种关注点(有些是层)的项目。应该可以在一时兴起的情况下将这些关注点拆分成单独的集合。因此，它们不应该耦合得太紧。对于您试图拆分的数据结构也是如此。实际上，您应该能够将相关的BC数据拆分到一个单独的数据库中。通过BCs获取数据的机制是另一回事，我猜如果不能解决这个问题，你可能会发现它很难做到。

尽管我不认为从数据端识别be可能是最好的想法，但这肯定是朝着正确方向迈出的一步:)

我喜欢Julie Lerman在这个话题上的观点http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

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

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

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

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

所以，是的，一定要使用有界上下文。这可以针对相同的数据存储。为了回答这个问题“是的，相同的表(DbSet)可以出现在许多上下文中。

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

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

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