在查看 Microsoft 的网站时，我发现他们不再推荐使用 Self-Tracking Entities。
下面的每个链接都是提到不使用 STE 的 MS 资源：
显示实体框架团队可用的模板： EF 设计器代码生成模板
有谁知道为什么微软不再推荐使用 STE？
问问题
6888 次
2 回答
12
（注意：由于我不为 MS 工作，这都是基于他们的公开声明和过去历史的推测）。
您发布的第一篇文章“有点”解释了原因，尽管不是很清楚：他们希望您使用更好的替代方案，并且无意修复或改进 STE。微软正在将 STE 放入“早期失败的实验”中，类似于 RDO、Remoting 或 LINQ2SQL——他们拿出一些东西来看看它工作得如何，但实际上并没有。
总的来说，微软总是承认 STE 是解决实际业务问题的第一步，但它们显然是不完整的。特别是，它们在将对象图附加到共享实体方面非常糟糕，它们不支持延迟加载，并且还有许多其他杂项限制。
MS 显然已经决定他们不会尝试清理它们（请注意，出于类似的原因，他们也弃用了 POCO 模板）。由于他们不打算修复或改进模板，他们希望人们停止将其用于新项目并转向更好的替代方案：
数据库上下文生成器
此模板将生成简单的 POCO 实体类和派生自 DbContext 的上下文。这是推荐的模板，除非您有理由使用下面列出的其他模板之一。
STE 的存在主要是为了支持实体断开连接并重新连接到其上下文的情况，尤其是在序列化场景（例如 WCF 或 Web 服务）中。在“标准”实体框架对象中，所有更改跟踪都是在上下文中完成的，将现有实体附加到上下文是有问题的。STE 使该过程变得更容易，但代价是使几乎所有其他事情变得非常困难。
从我所见和经验来看，DbContext它应该是解决这个问题的更好选择，尽管它实际上并没有复制STE 所做的事情。EF 的重度用户之间的普遍共识似乎是，端到端序列化您的 EF 实体是一个非常糟糕的主意。相反，您应该使用 DTO 和AutoMapper之类的东西在 DTO 和 EF 对象之间进行映射。
于 2012-09-17T16:32:31.443 回答
6
我创作了 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 。
干杯，托尼·斯尼德
于 2013-11-18T13:30:23.233 回答