在查看微软的网站时，我发现他们不再建议使用自我追踪实体。
以下每个链接都是MS资源，提到不使用STE：
显示Entity Framework团队可用的模板： EF Designer Code Generation Templates
有谁知道为什么微软不再推荐使用STE？
答案 0 :(得分：12)
（注意：因为我不适用于MS，所以猜想基于他们的公开声明和过去的历史记录）。
您发布的第一篇文章“有点”解释了原因，虽然不是很清楚：他们希望您使用更好的替代方案，而无意修复或改进STE。微软正在将STEs放入“早期失败的实验”中，类似于RDO或Remoting或LINQ2SQL--他们提出了一些看法，看看它有多好用，但事实并非如此。
总的来说，微软始终承认STEs是解决实际业务问题的第一步，但它们显然是不完整的。特别是，在使用共享实体附加对象图时，它们 非常糟糕 ，它们不支持延迟加载，并且还有许多其他的限制。
MS显然已经决定他们不会尝试清理它们（注意他们也因为类似的原因而弃用了POCO模板）。由于他们不打算修复或改进模板，他们希望人们停止将其用于新项目，并转向更好的替代方案：DbContext Generator
此模板将生成简单的POCO实体类和从DbContext派生的上下文。除非您有理由使用下面列出的其他模板之一，否则这是推荐的模板。
STE主要用于支持实体断开连接并重新连接到其上下文的情况，尤其是在序列化方案（例如WCF或Web服务）中。在“标准”实体框架对象中，所有更改跟踪都是在上下文中完成的，并且将existig实体附加到上下文是有问题的。 STEs使这个过程变得更容易，但代价是几乎所有其他东西都很难。
从我所看到和经历过的DbContext它应该是解决这个问题的更好的替代方案，尽管它实际上并没有复制 STEs所做的事情。 EF重度用户的普遍共识似乎是将端到端的EF实体序列化是一个非常糟糕的主意。相反，您应该使用DTO和AutoMapper之类的东西在DTO和EF对象之间进行映射。
答案 1 :(得分：6)
我创作了可追踪实体，以替代STE：https://trackable.codeplex.com。它被部署为一组NuGet包和Visual Studio扩展。有一组项目模板，包含用于ASP.NET Web API脚手架的T4模板，以及用于生成WCF服务的项模板。
这是我写的一篇博客文章，将TE与STE的比较：http://blog.tonysneed.com/2013/11/18/trackable-entities-versus-self-tracking-entities。
干杯， Tony Sneed