实体框架（4.1）中具有一对多双向关系有哪些优点和缺点？

我正在开发一个利用实体框架的新项目。我爱上了关系反向，两种类型的导航属性都会让我的生活变得更加轻松。问题是：我们的项目经理认为使用此设施可能会导致错误，因此建议我们不要使用它。实体框架（4.1）中具有一对多双向关系有哪些优点和缺点？

比方说，我们有类别和产品：

public class Product 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public virtual Category Category { get; set; } 
} 

public class Category 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<Product> Products { get; set; } 
}

他说，一个也可以，错误，productZ.Category设置为categoryX，然后做一个categoryY.Products.Add（productZ）为例。那么当我们保存上下文时，什么样的关系会持续存在？最后一个？好的，如果第一个是正确的类别呢？而这种错误很难调试（我同意这一点）。

我不认为这种情况会发生，但我真的尊重他的意见，他比我更有经验，但我真的想说服他让我们具有双向导航属性，唯一的理由是：if每个人都在这样做，那么它不能这么糟糕。 :)

你们可以帮我一些更坚实的论点？

来源

2011-10-05 Henrique Miranda

人们可以通过错误...

人们也可以编写单元测试，以验证代码集预期的关系。您始终可以犯错误并删除导航属性不是避免此问题的解决方案。解决方案是验证您的代码是否符合预期=测试和代码覆盖率。

你问的是更多关于设计你的课程 - 而不是关于错误。双方都有导航属性有意义吗？您是将产品添加到产品类别还是将产品分类？你需要提供两种方式吗？产品能否存在没有类别？您是分开处理产品和类别还是聚合？基于对这些问题的回答，您有时可能会发现关系一侧的导航属性不是必需的。

来源

2011-10-05 14:48:13

当我们添加一个新产品时，我们主要将这个类别分配给产品，然后插入它。有时我们会使用产品及其类别，但也需要从一个类别（甚至是所有类别）访问所有产品。看到我的观点？ –

单个类别或所有类别的产品都可以通过对产品进行单独查询来访问。 –

我会同意你的项目经理，特别是在阅读“他比我更有经验”时，因为它表明至少有些团队有点绿色（你自己？），并且可能会犯这种错误提及。您所描述的问题很像将值存储在多个数据库中（有时是必需的恶意），而不是将其中一个数据库设置为主数据库。

虽然双向“关系”可能会让事情变得更容易一些，但是通过简单的编码错误就会增加混淆数据的风险，这并不那么容易。你可以在不添加双向支持的情况下导航（可能不是简单的声明，但可以完成），但我必须有强烈的使用它们的论据。

来源

2011-10-05 14:46:36

那么，缺乏经验并不像缺乏经验一样。这就是说，是的，我担心他对球队没有足够的信心让这个潜在的麻烦制造者打开。 –

我并不是说没有经验，所以我希望它没有遇到这种情况。但把这样的方法交给一个经验较少的团队就好像给一个年龄较大的孩子递枪。很可能，没有什么不好的事情会发生，但潜力更大。使用可以完全封装的代码，您可以降低风险，但是当您谈论自己的域模型时，无法完全封装以保护开发人员不受自己的影响。除非有人能说服我为什么需要，否则我会发现风险太大。 –

我的想法是“如果这是非常危险的，那么为什么在全世界每一个EF范例都实现了它，并且它们都没有警告这类问题？”。我认为应该真的有人为了犯这种错误。 –

实体框架（4.1）中具有一对多双向关系有哪些优点和缺点？

回答

相关问题