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

Question

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

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

• 显示实体框架团队可用的模板： EF Designer代码生成模板

• 自我追踪实体

• N层应用的推荐技术

有谁知道为什么微软不再推荐使用STE？

Answer 1

（注意：因为我不为MS工作，所以这是根据他们的公开声明和过去的历史推测的所有猜想 ）。

您发布的第一篇文章“有点”解释了原因，虽然不是很清楚：他们希望您使用更好的替代方案，而无意修复或改进STE。 微软正在将STEs置于“早期失败的实验”中，类似于RDO或Remoting或LINQ2SQL--他们提出了一些看法，看看它有多好用，但事实并非如此。

总的来说，微软始终承认STEs是解决实际业务问题的第一步，但它们显然是不完整的。 特别是，它们在将对象图附加到共享实体时非常糟糕 ，它们不支持延迟加载，并且还有许多其他的其他限制。

MS显然已经决定他们不会尝试清理它们（注意他们也因为类似的原因而弃用了POCO模板）。 由于他们不打算修复或改进模板，他们希望人们停止将其用于新项目并转向更好的替代方案：

MSDN数据库

DbContext Generator

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

STE主要用于支持实体断开连接并重新连接到其上下文的情况，尤其是在序列化方案（例如WCF或Web服务）中。 在“标准”实体框架对象中，所有更改跟踪都是在上下文中完成的，并且将existig实体附加到上下文是有问题的。 STEs使这个过程变得更容易，但代价是几乎所有其他东西都很难。

根据我所看到的和DbContext经验，它应该是解决这个问题的更好的替代方案，尽管它实际上并没有复制 STE所做的事情。 EF重度用户的普遍共识似乎是将端到端的EF实体序列化是一个非常糟糕的主意。 相反，您应该使用DTO和AutoMapper之类的东西在DTO和EF对象之间进行映射。

Answer 2

我创作了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