0

据我了解（如果我弄错了，请纠正我），它们之间有关系的实体类可以通过多种方式定义——（1）通过使用一个属性来表示一个标量键加上一个导航属性或（2 ) 仅使用导航属性。

如果您使用数据注释，我相信您唯一的选择是同时使用标量键和导航属性，而使用 Fluent API 两种方法都可用。

我的问题是采取哪种方法？各自的优缺点是什么？（这是关于外键和导航属性的两种选择......不是关于数据注释与流利的。

正如我所看到的，它归结为这些因素/担忧

  1. 同时拥有标量属性和导航属性可以被视为“弄脏”类。
  2. 只有导航属性需要调用 Includes() 才能访问 FK 值。我没有查看正在发送的 SELECT 语句，但我怀疑正在执行 JOIN 并且正在发回不需要的数据。
  3. 拥有标量属性将排除对 Include() 调用的需要。
  4. 正如我在上一个 SO 问题（相关问题）中所暗示的那样，看起来导航属性不能用作复合键的一部分，因此将被迫包含额外的标量键。如果你必须为一个属性做这件事，那么在你的所有类中保持一致是有意义的。

我错过了什么吗？一般来说，定义外键和导航属性的推荐方法是什么？为什么要同时提供这两种方法，因为它似乎混淆了水域？我查看了很多教程，并看到了这两种方法的混合。

谢谢你。

4

1 回答 1

1

(1) 通过使用属性来表示标量键和导航属性，或者 (2) 仅使用导航属性。

这就是外键和独立关联之间的区别。

如果您使用数据注释，我相信您唯一的选择是同时使用标量键和导航属性，而使用 Fluent API 两种方法都可用。

不，数据注释只是另一个提示。默认约定会自动识别导航属性。

同时拥有标量属性和导航属性可以被视为“弄脏”类。

是的，但是由于具有标量属性的两种关联类型的不同性质使得一些开发任务更简单。

只有导航属性需要调用 Includes() 才能访问 FK 值。我没有查看正在发送的 SELECT 语句，但我怀疑正在执行 JOIN 并且正在发回不需要的数据。

是的。Include意味着获取数据，但如果您只需要在 linq-to-entities 查询中访问 FK，则不需要使用它。例子：

 var children = from c in context.Children
                where c.Parent.Id == 123
                select c;

此查询通过并在内部生成联接访问“FK” Parent，但不获取父级。

拥有标量属性将排除对 Include() 调用的需要。

否Include。取决于导航属性，而 FK 属性本身不会创建关联。您始终必须在关系的至少一侧具有导航属性（在我的示例中Parent或Child在我的示例中）。

看起来导航属性不能用作复合键的一部分

是的。如果您需要复合键，则需要在实体上公开外键。

还有其他相关问题。

于 2012-10-07T09:45:38.163 回答