EF4 独立协会 - 为啥要避免它们？

Posted 2023-02-26

【中文标题】EF4 独立协会 - 为啥要避免它们？

【英文标题】：EF4 Independent Associations - Why avoid them?EF4 独立协会 - 为什么要避免它们？

【发布时间】：2011-01-16 02:08:26

【问题描述】：

我在 MSDN 上看到了这条评论（link 和 link）：

“请注意，通常应避免独立关联，因为诸如 N-Tier 和并发变得更加困难。”

我是 EF4 的新手，我正在构建一个 n-Tier Web 应用程序。这听起来像是一个重要的陷阱。谁能给我解释一下这是什么意思？

【参考方案1】：

我认为这是个人喜好。最初，创建 EF 是为了只使用 indep。关联并与更经典的 ERM 方法保持一致。然而，我们大多数开发人员都非常依赖 FK，这让生活变得非常复杂。因此，MS 在 EF4 中为我们提供了 FK，这意味着不仅将 FK 作为依赖实体中的属性，而且通过概念模型中的约束来定义关系，而不是隐藏在映射中。还有一些关系只能用独立关联来定义：多对多和唯一外键。请注意，如果您打算使用 RIA 服务（听起来不像），那么 RIA 只能识别 FK 关联。

因此，如果您更喜欢利用独立关联，您仍然绝对可以在 EF4 中使用它们。他们完全支持。但正如 James 所建议的那样，还有一些陷阱需要注意……由于 EF 尤其适用于图形的方式，您需要更明确地做一些事情。或者您确实只需要该 FK 的情况，例如，您有客户的 ID 但没有实例。您可以创建一个订单，但如果没有很好的 CustomerID FK 属性，您必须做一些额外的操作才能在其中获取该 CustomerID。

第

【参考方案2】：

如果您是 EF 新手并且从 EF4 开始，简单的答案是忽略这一点 - 您几乎肯定会使用外键关联而不是独立关联。

外键关联由数据库中的外键关系支持，并且该关系在概念模型中明确描述。这种关联对 EF4 来说是新的，我理解这是人们在独立关联问题之后做出的让步。

严格来说，如果您想分离存储架构和概念架构（这是 EF 的重点），您不希望您的概念架构知道外键之类的东西，因为它们是数据库（即存储）概念。早期版本的 EF 遵循这种方法，我们有一个叫做独立关联的东西。

将独立关联视为由 EF 跟踪的关联，无需了解基础外键。 EF 仍然支持这一点，但它们有很大的弱点。

除非您另有说明，否则 VS2010 中的 EF4 将使用您的外键并创建外键关系。总的来说，这些工作如你所料。还有一些陷阱 - 例如。围绕级联删除。

如果你想学习 EF - 我可以推荐这本书：

http://learnentityframework.com/learnentityframework/

你想知道的一切，解释得很清楚。

【讨论】：

奥基多克。但是，n-tier 和并发带来的具体问题是什么？

除了模式差异之外的主要区别在于具有独立关联的实体不会在概念层中公开外键。该关联被维护在一个单独的对象中。根据您设计应用程序的方式，在层之间传递这些额外信息会更加复杂。外键关联更容易使用，因为您可以直接在实体上设置外键 - 或修改公开的相关实体/实体集。

在我看来“不太容易使用”并不一定会转化为“避免”。后者表明存在特定的陷阱。有没有关于这些陷阱的文章？ （我确实有 Julia Lerman 的书，顺便说一句。）

“不那么容易”不等于“更难”吗？ AFAIK 没有什么可以专门阻止 N 层或并发性。我认为您可能对评论读了很多 - 这不是官方 MSDN 文档的一部分，是吗？这是我相信的论坛上的评论？我的主要观点仍然是，您可能无论如何都不应该使用这些关联 - 它们已被更好的东西所取代 - 特别是因为人们有时会发现它们令人困惑且难以/不自然地使用。

不太容易 = 更困难，但它与“避免”不同。该评论来自版主@Microsoft，因此我给予了很大的重视。我想我喜欢独立关联，因为它们将外键标量排除在我的 POCO 之外。例如，在您的 POCO 中同时拥有 CustomerID 和 Customer 引用不是更令人困惑吗？也许我误解了这个概念？