Question

我正在开发一个使用Entity Framework的新项目。我爱上了关系逆转，两种类型的导航属性都会让我的生活变得更加轻松。问题是：我们的项目经理认为使用此设施可能会导致错误，因此建议我们不要使用它。

假设我们有类别和产品：

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）。那么当我们保存上下文时，将保持什么样的关系？最后一个？好吧，如果第一个是正确的类别怎么办？并且这种错误很难调试（我同意）。

我不认为这种情况会发生，但我真的很尊重他的意见，他比我更有经验，但我真的想说服他让我们拥有双向导航属性，而我唯一的论点是：如果每个人正在做它然后它不能这么糟糕。：）

你们能帮助我一些更坚实的论点吗？

Answer 1

一个人可能是错误的......

还可以编写单元测试来验证代码设置预期关系。您总是可以犯错，删除导航属性不是解决问题的方法。解决方案是验证您的代码是否符合预期=测试和代码覆盖率。

您要求的更多是关于设计课程 - 而不是错误。双方都有导航属性是否有意义？您是将产品添加到类别还是将产品分类？你需要提供两种方式吗？产品可以没有类别吗？您是单独处理产品和类别还是汇总？根据这些问题的答案，您有时可以发现关系一侧的导航属性不是必需的。

Answer 2

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

虽然双向“关系”可能会使事情变得更容易，但是通过一个简单的编码错误来增加数据混乱的风险并不容易。您可以在不添加双向支持的情况下导航（也许不是简单的声明，但可以完成），我必须有强大的参数来使用它们。

在Entity Framework（4.1）中拥有一对多双向关系的优点和缺点是什么？

2 个答案: