问题描述
我在 MSDN 上看到了这条评论(link 和 link):
I saw this comment on MSDN (link and link):
"请注意，通常应避免使用独立关联，因为诸如N 层和并发变得更加困难."
我是 EF4 的新手，我正在构建一个 n 层 Web 应用程序.这听起来像是一个重要的陷阱.有人可以向我解释一下这是什么意思吗?
I'm new to EF4 and I'm building an n-Tier web app. This sounds like an important pitfall. Can someone explain to me what this means?
推荐答案
我认为这是个人喜好.最初，创建 EF 的目的是仅使用 indep.关联并与更经典的 ERM 方法保持一致.然而，我们大多数开发人员都非常依赖 FK，这让生活变得非常复杂.所以 MS 在 EF4 中给了我们 FK，这意味着不仅将 FK 作为依赖实体中的属性，而且关系是通过概念模型中的约束定义的，而不是隐藏在映射中.还有一些关系只能用 indep 关联来定义:多对多和唯一的外键.请注意，如果您计划使用 RIA 服务(听起来不像)，则 RIA 仅识别 FK 关联.
I think it's personal preference. Originally, EF was created to only use indep. associations and aligned with a more classic ERM approach. However, most of us devs are so dependent on FKs that it made life very complex. So MS gave us FKs in EF4 which meant not only having the FK as a property in the dependent entity but the relationships are defined through constraints in the conceptual model rather than buried in the mappings. There are still a few relationships that you can only define with an indep association: many to many and unique foreign keys. Note that if you are planning to use RIA Services (doesn't sound like it) that RIA only recognizes FK associations.
因此，如果您更喜欢利用独立关联，您仍然绝对可以在 EF4 中使用它们.他们完全支持.但正如 James 所建议的，还有一些陷阱需要注意……由于 EF 处理图形的方式，您需要更明确地做这些事情.或者你只想要那个 FK 的情况，例如，你有一个客户的 ID，但你没有实例.您可以创建一个订单，但如果没有那个不错的 CustomerID FK 属性，您必须做一些额外的处理才能在那里获得那个 CustomerID.
So if you prefer to leverage the independent associations you still absolutely can use them in EF4. They are totally supported. But as James suggests, there are a few more traps to be aware of...things that you'll need to do more explicitly because of the way EF works with graphs especially. Or that case where you do just want that FK , e.g., you have the ID of a customer but you don't h ave the instance. You could create an order but without that nice CustomerID FK property, you have to do some extra juggling to get that CustomerID in there.
第
这篇关于EF4 独立协会 - 为什么要避免它们?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！