entity framework自我跟踪实体不是Microsoft推荐的
在查看Microsoft的网站时，我发现他们不再建议使用自我跟踪实体。
下面的每个链接都是MS资源，提到不使用STE：
-
显示entity framework团队可用的模板： EF Designer代码生成模板
-
自我追踪实体
-
N层应用的推荐技术
有谁知道为什么微软不再推荐使用STE？
（注意：因为我不为MS工作，所以这是根据他们的公开声明和过去的历史推测的所有猜想 ）。
您发布的第一篇文章“有点”解释了原因，虽然不是很清楚：他们希望您使用更好的替代方案，而无意修复或改进STE。 微软正在将STEs放入“早期失败的实验”中，类似于RDO或Remoting或LINQ2SQL – 他们提出了一些看法，看看它有多好用，但事实并非如此。
总的来说，微软始终承认，STEs是解决实际业务问题的第一步，但它们显然是不完整的。 特别是，他们在将对象图附加到共享实体时非常糟糕 ，他们不支持延迟加载，并且还有许多其他的其他限制。
MS显然已经决定他们不会尝试清理它们（注意他们也因为类似的原因而弃用了POCO模板）。 由于他们不打算修复或改进模板，他们希望人们停止将其用于新项目，并转向更好的替代方案：
MSDN数据库
DbContext Generator
该模板将生成简单的POCO实体类和从DbContext派生的上下文。 这是推荐的模板，除非您有理由使用下面列出的其他模板之一。
STE主要用于支持实体断开连接并重新连接到其上下文的情况，尤其是在序列化方案（例如WCF或Web服务）中。 在“标准”entity framework对象中，所有更改跟踪都是在上下文中完成的，并且将existig实体附加到上下文是有问题的。 STEs使这个过程变得更容易，但代价是几乎所有其他东西都很难。
根据我所看到的和DbContext经验，它应该是解决这个问题的更好的替代方案，尽管它实际上并没有复制 STE所做的事情。 EF重度用户的普遍共识似乎是将端到端的EF实体序列化是一个非常糟糕的主意。 相反，您应该使用DTO和AutoMapper之类的东西在DTO和EF对象之间进行映射。
我创建了Trackable Entities作为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