我有一些误解,我的对象应该如何在关系数据库结构中表示。
例如,如果我有一个看起来像这样的简单表结构:
如果我基于此生成实体框架模型,它将如下所示:
正如你所看到的那样,这是多对多的关联。 (任何菜包含许多成分,任何成分可用于许多菜)
现在,如果我需要一些额外的参数,例如菜肴中的成分数量,该怎么办? (当然,对于任何不同的菜肴,每种成分通常都是不同的数字。)
如果我将一些额外的列直接添加到Dish_FooIngridient
表,它会破坏自动模型生成的精确性,然后我必须在EF模型设计器中手动修复关联,然后使用一些繁琐的查询来操作对象。因为它会生成如下:
如您所见,现在还有其他冗余属性,我不需要。有没有更好的方法来管理它?也许使用复杂的属性或继承的实体,或其他什么?
答案 0 :(得分:1)
正如在Apress的“实体框架4.0食谱”中所建议的那样,在没有有效载荷的情况下设计多对多关系并不是一个很好的做法。
不幸的是,一个以多个无负载,多对多关系开头的项目通常最终会产生多个有效负载,多对多关系。重构模型,特别是在开发周期的后期,以适应多对多关系中的有效载荷可能是乏味的。不仅引入了其他实体,而且通过关系的查询和导航模式也发生了变化。一些开发人员认为,每个多对多关系应该从一些有效载荷开始,通常是一个合成密钥,因此不可避免地增加更多有效载荷对项目的影响要小得多。所以这是最好的做法。如果你有一个免费的,多对多的关系,并且你认为它有可能随着时间的推移而改变以包含一个有效载荷,那么从一个额外的身份列开始 链接表。将表导入模型时,您将获得两个一对多关系,这意味着您编写的代码和您拥有的模型将为项目成熟时出现的任意数量的其他有效负载列做好准备。额外的整数标识列的成本通常是为了保持模型更多而付出的相当小的代价 柔性的。
答案 1 :(得分:0)
我不明白为什么。将字段添加到Dish_FoodIngredient并为其提供主键。将该表添加到您的模型中即可。您可能需要在代码中进行一些重构,但不要因此而责怪EF。
答案 2 :(得分:-1)
双击Model.edmx文件,然后在对象旁边的空白区域中,右键单击并单击“从数据库更新模型...”,然后单击“完成”,它将刷新表格。 / p>