C# Microsoft不推荐的实体框架自跟踪实体

在查看微软的网站时，我发现他们不再建议使用自跟踪实体

下面的每个链接都是提到不要使用STE的MS资源：

• 显示实体框架团队可用的模板：

有人知道为什么微软不再推荐使用STEs吗？

（注意：由于我不为微软工作，这都是基于他们的公开声明和过去历史的猜测）

您发布的第一篇文章“有点”解释了原因，但不是很清楚：他们希望您使用更好的替代方案，并且无意修复或改进STE。微软正在把STE放入“早期失败实验”的垃圾箱，类似于RDO、远程处理或LINQ2SQL——他们把一些东西放出来，看看它工作得有多好，但实际上没有

总的来说，微软一直承认STE是解决实际业务问题的第一个尝试，但它们显然是不完整的。特别是，它们在使用共享实体附加对象图方面非常糟糕，它们不支持延迟加载，并且有许多其他的限制

MS显然已经决定不再尝试清理它们（注意，出于类似的原因，他们也不推荐POCO模板）。由于他们不打算修复或改进模板，他们希望人们停止在新项目中使用模板，转而使用更好的替代方案：

DbContext生成器

此模板将生成简单的POCO实体类和从DbContext派生的上下文。这是推荐的模板，除非您有理由使用下面列出的其他模板之一

STE的存在主要是为了支持实体断开连接并重新连接到其上下文的情况，特别是在序列化场景中（例如WCF或web服务）。在“标准”实体框架对象中，所有更改跟踪都是在上下文中完成的，将现有实体附加到上下文是有问题的。STEs使这一过程变得更容易，但代价是几乎所有其他事情都变得非常困难

---

从我对

DbContext

的了解和体验来看，它应该是解决这个问题的更好的选择，尽管它实际上并没有复制STEs所做的。EF大量用户的普遍共识似乎是，端到端序列化EF实体是一个非常糟糕的主意。相反，您应该使用DTO和类似的东西在DTO和EF对象之间进行映射。

我编写了可跟踪实体作为STE的替代品：。它部署为一组NuGet包和Visual Studio扩展。有一组项目模板，包括用于ASP.NET Web API脚手架的T4模板，以及用于生成WCF服务的项模板

这是我写的一篇博客文章，比较了TE和STE

干杯，

---

托尼·斯内德（Tony Sneed）

今天早些时候你没问过吗？我不是微软，我只能猜原因是什么。这就是说，要求模型层之上的每一层都包含自跟踪逻辑的正确实现听起来与使用N层体系结构一开始应该实现的目标完全相反。例如，您无法通过可互操作的web服务轻松公开您的服务层。另一个假设是，STE听起来相当“神奇”，可能最终没有做用户想要做的事情，没有办法定制行为。它在你的一个链接中说“自我跟踪实体不能与代码优先模型一起使用”@CodesInChaos我在你链接的帖子中没有问这个问题。这是巧合。当我发布我的问题时，这个问题还不存在。对于Visual Studio 2012，创建edmx模型将自动包括[当前]推荐的T4模板，这将使初学者更容易入门，并提供一个合适的“默认选项”。