“请注意，通常应该避免独立关联，因为 N-Tier 和并发之类的事情变得更加困难。”
我是 EF4 的新手，我正在构建一个 n-Tier Web 应用程序。这听起来像是一个重要的陷阱。有人可以向我解释这是什么意思吗？
问问题
2302 次
2 回答
7
我认为这是个人喜好。最初，创建 EF 是为了只使用 indep。关联并与更经典的 ERM 方法保持一致。然而，我们大多数开发人员都非常依赖 FK，这让生活变得非常复杂。因此，MS 在 EF4 中为我们提供了 FK，这意味着不仅将 FK 作为依赖实体中的属性，而且关系是通过概念模型中的约束来定义的，而不是隐藏在映射中。还有一些关系只能用独立关联来定义：多对多和唯一的外键。请注意，如果您计划使用 RIA 服务（听起来不像），那么 RIA 只能识别 FK 关联。
因此，如果您更喜欢利用独立关联，您仍然绝对可以在 EF4 中使用它们。他们完全支持。但正如 James 所建议的那样，还有一些陷阱需要注意……由于 EF 尤其适用于图表的方式，您需要更明确地做这些事情。或者您确实只需要该 FK 的情况，例如，您有客户的 ID 但没有实例。您可以创建一个订单，但如果没有那个不错的 CustomerID FK 属性，您必须做一些额外的操作才能在其中获取该 CustomerID。
hth
于 2011-01-30T23:17:16.487 回答
3
如果您是 EF 新手并且从 EF4 开始，那么简单的答案就是忽略这一点 - 您几乎肯定会使用外键关联而不是独立关联。
外键关联由数据库中的外键关系支持，并且该关系在概念模型中明确描述。这种关联对 EF4 来说是新的，我理解这是人们对独立关联的问题之后的让步。
严格来说，如果您想分离存储架构和概念架构（这是 EF 的重点），您不希望您的概念架构知道外键之类的东西，因为这些是数据库（即存储）概念。早期版本的 EF 遵循这种方法，我们有一个叫做独立关联的东西。
将独立关联视为 EF 在不了解基础外键的情况下跟踪的关联。EF 仍然支持这一点，但它们有很大的弱点。
除非您另有说明，否则 VS2010 中的 EF4 将使用您的外键并创建外键关系。总的来说，这些工作如你所料。仍然存在一些问题——例如级联删除。
如果你想学习 EF - 我可以推荐这本书：
http://learnentityframework.com/learnentityframework/
你想知道的一切，都解释得很清楚。
于 2011-01-16T02:17:08.090 回答