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