有人可以澄清我对实体框架中关联修复代码（T4 生成的 POCO）的想法吗？
最近关于修复的评论指出“例如，代码优先不使用它们，一切仍然有效”。
我对这个修复的东西有点困惑 - 似乎没有人喜欢它 - 我当然不喜欢它污染我的 POCO（尽管我的原因是因为性能问题）但我不清楚在什么情况下我会真的需要它。
如果我在 ASP.NET 应用程序中使用短暂的数据上下文生命周期，即每个页面请求 (UoW) 的新上下文，那么我是否应该担心是否从 T4 模板中删除所有关联修复代码（终于干净整洁的 POCO 了）？
编辑
我在 MSDN 'Fixup Goes Crazy' 上找到了这个讨论，它确实提供了一些说明： http://social.msdn.microsoft.com/Forums/pl-PL/adodotnetentityframework/thread/a757d1fb-1339-422e-a03a-2b90ce4cd692
Can someone clarify my thinking on association fixup code in Entity Framework (T4 generated POCOs) please?
A recent comment regarding fix-up stated 'For example code-first doesn't use them and everything still works'.
I'm a little confused on this fixup stuff - seems no-one likes it - I certainly don't like it polluting my POCOs (though my reason is because of performance issues) yet it is not clear to me in what scenarios would I really need it.
If I am using short-lived data context lifetimes i.e. new context for each page request (UoW) in an ASP.NET application, then should I worry at all if I were to rip out all the association fix-up code from the T4 template (finally nice clean POCOs)?
EDIT
I found this discussion on MSDN 'Fixup Goes Crazy' which does provide some clarification: http://social.msdn.microsoft.com/Forums/pl-PL/adodotnetentityframework/thread/a757d1fb-1339-422e-a03a-2b90ce4cd692
发布评论
评论（1）
Fix up只是T4模板生成的代码。 EF 根本不需要它，EF 也不使用它。 ADO.NET 团队做出了一些假设，即 POCO 应该很聪明，如果您在一侧更改导航属性，则可以修复其导航属性。如果您手动编写实体而不是使用 T4 模板，并且您将省略所有修复逻辑，它仍然可以工作。这也是您不需要首先修复代码的原因。
您可以修改 T4 模板并删除所有修复逻辑。
Fix up is just a code generated by T4 template. EF doesn't need it at all and EF doesn't use it. It was some assumption done by ADO.NET team that POCOs should be clever and fix their navigation properties if you change it on one side. If you write your entities manually instead of using T4 template and you will omit all fix up logic it will still work. That is also the reason why you don't need fix ups in the code first.
You can modify your T4 template and remove all fix up logic.