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

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

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

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

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

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

因此,无论如何都要使用有界上下文.这可以针对SAME数据存储.并回答问题,因为"是的,相同的表(DbSet)可以出现在许多情况下.

Answer 2

这种方法存在一些潜在的问题(IMO):

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

试图转向更好的结构并不是件坏事:)但是,正如Mark Oreta所说,我可能不会为EF结构而烦恼.

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

如果您沿着分割数据的路线走下去,那么您需要将其分开.

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

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