entity-framework - Entity Framework 多对多问题

Question

请帮助EF n00b设计他的数据库。
我有几家公司生产几种产品，因此公司与产品之间存在多对多的关系。我有一个与它们相关的中间表Company_Product。

每个公司/产品组合都有唯一的SKU。例如，Acme小部件的SKU为123，而Omega小部件的SKU为456。

EF生成了一个模型，该模型在company和Company_Product表之间具有1:*的关系，在product和Company_Product表之间具有1:*的关系。我真的想要公司与产品之间的关系。但是，最重要的是，无法直接从模型访问SKU。

我是否需要将SKU放在自己的表中并编写联接，还是有更好的方法？

Answer 1

可以肯定的是，我刚刚在一个新的VS2010项目(EFv4)中对此进行了测试，这是我发现的内容:

当中间的关联表(Company_Product)仅将2个外键指向其他表(CompanyID和ProductID)时，然后将所有3个表添加到设计器中，最终会为多对多关系建模。它甚至不会为Company_Product表生成一个类。每个公司都有一个产品集合，每个产品都有一个公司集合。

但是，如果您的关联表(Company_Product)具有其他字段(例如SKU，它自己的主键或其他描述性字段，例如日期，描述等)，则EF建模器将创建一个单独的类，它会执行您要执行的操作我已经看过了。

使类与公司和产品之间的关系为1:*并不是一件坏事，并且您仍然可以通过一些简单的查询来获取所需的数据。

// Get all products for Company with ID = 1
var q =
    from compProd in context.Company_Product
    where compProd.CompanyID == 1
    select compProd.Product;

的确，例如，当您已经加载实体对象时，仅浏览模型的关系并不容易，但这就是数据层的用途。封装获取所需数据的查询。如果您真的想摆脱该中间Company_Product类，并在类模型中直接表示多对多，则必须精简Company_Product表以仅包含2个外键，并摆脱掉SKU。

实际上，我不应该说您必须这样做...您可能可以在设计器中进行一些编辑并以这种方式进行设置。我将尝试并进行报告。

更新

将SKU保留在Company_Product表中(这意味着我的EF模型具有3个类，而不是2个；它创建了Company_Payload类，其他2个表中带有1:*)，我试图在Company和Product之间直接添加关联。我遵循的步骤是:

右键单击设计器

中的Company类

添加>关联

在左侧将“End”设置为Company(应该已经)

在产品

的右侧设置“结束”

将两个多重性都更改为“*(许多)”

导航属性应命名为“产品”和“公司”

单击确定。

右键单击模型中的关联>单击“表映射”。

在“添加表或 View ”下，选择“Company_Product”

将公司-> ID(在左侧)映射到CompanyID(在右侧)

将产品-> ID(在左侧)映射到ProductID(在右侧)

但是，它不起作用。它给出了这个错误:
错误3025:映射片段的问题始于第175行:必须为表Company_Product的所有关键属性(Company_Product.SKU)指定映射。

因此该特定关联无效，因为它使用Company_Product作为表，但未将SKU字段映射到任何内容。

另外，当我研究此问​​题时，我从Entity Framework 4.0 Recipies一书中遇到了这个“最佳实践”窍门(请注意，对于带有额外字段的关联表，除了2个FK之外，它们将额外字段称为“有效负载” “。在您的情况下，SKU是Company_Product中的有效负载)。

Best Practice

Unfortunately, a project that starts out with several, payload-free, many-to-many relationships often ends up with several, payload-rich, many-to-many relationships. Refactoring a model, especially late in the development cycle, to accommodate payloads in the many-to-many relationships can be tedious. Not only are additional entities introduced, but the queries and navigation patterns through the relationships change as well. Some developers argue that every many-to-many relationship should start off with some payload, typically a synthetic key, so the inevitable addition of more payload has significantly less impact on the project.

So here's the best practice. If you have a payload-free, many-to-many relationship and you think there is some chance that it may change over time to include a payload, start with an extra identity column in the link table. When you import the tables into your model, you will get two one-to-many relationships, which means the code you write and the model you have will be ready for any number of additional payload columns that come along as the project matures. The cost of an additional integer identity column is usually a pretty small price to pay to keep the model more flexible.

(从第2章“实体数据建模基础知识”，“2.4。使用有效负载建模多对多关系”)

听起来像个好建议。特别是因为您已经拥有有效负载(SKU)。