在浏览 Microsoft 的网站时，我发现他们不再推荐使用 self 跟踪实体。
下面的每个链接都是提到不使用 STE 的 MS 资源:
显示 Entity Framework 团队提供的模板: EF Designer Code Generation Templates
有谁知道为什么 Microsoft 不再建议使用 STE？
最佳答案
(注意:由于我不为 MS 工作，所以这都是基于他们的公开声明和过去历史的猜想)。
您发布的第一篇文章“有点”解释了原因，但不是很清楚:他们希望您使用更好的替代方案，无意修复或改进 STE。 Microsoft 正在将 STE 放入“早期失败实验”的容器中，类似于 RDO 或 Remoting 或 LINQ2SQL - 他们将一些东西放出来看看它的工作情况如何，但事实并非如此。
一般来说，Microsoft 始终承认 STE 是解决实际业务问题的先行者，但它们显然不完整。特别是，它们非常不擅长将对象图附加到共享实体，它们不支持延迟加载，并且还有许多其他的限制。
MS 显然已经决定他们不会尝试清理它们(请注意，出于类似的原因，他们也弃用了 POCO 模板)。由于他们不打算修复或改进模板，因此他们希望人们停止将其用于新项目并转向更好的替代方案:
DbContext Generator
This template will generate simple POCO entity classes and a context that derives from DbContext. This is the recommended template unless you have a reason to use one of the other templates listed below.
STE 的存在主要是为了支持实体断开连接并重新连接到其上下文的情况，尤其是在序列化场景(例如 WCF 或 Web 服务)中。在“标准” Entity Framework 对象中，所有更改跟踪都是在上下文中完成的，将现有实体附加到上下文是有问题的。 STE 让这个过程变得更容易，但代价是几乎所有其他事情都变得非常困难。
根据我对 DbContext 的了解和体验，它应该是解决此问题的更好选择，尽管它实际上复制 STE 所做的事情. EF 重度用户之间的普遍共识似乎是端到端序列化 EF 实体是一个非常糟糕的主意。相反，您应该使用 DTO 和类似 AutoMapper 的东西在 DTO 和 EF 对象之间进行映射。
关于c# - Microsoft 不推荐的 Entity Framework 自跟踪实体，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12462319/