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

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (9)

在查看微软的网站时,我发现他们不再推荐使用自我跟踪实体。

下面的每个链接都是一个MS资源,其中提到不使用stes:

1.显示实体框架小组可用的模板:EF设计器代码生成模板

2.自跟踪实体

3. 推荐的N层应用技术

有人知道为什么微软不再建议使用stes吗?

提问于
用户回答回答于

你发布的第一篇文章“有点”解释了原因,虽然并不十分清楚:他们希望你使用更好的替代方案,而不打算修复或改进STE。微软正在把stes放进“早期失败的实验”的垃圾桶里,类似于RDO、Remoting或LINQ2SQL--他们拿出一些东西来看看它有多好,而它却没有。

总的来说,微软一直认为stes是解决真正业务问题的第一次尝试,但它们显然是不完整的。特别是,在使用共享实体附加对象图时,它们不支持延迟加载,而且还有许多其他的限制。

显然,微软已经决定不再尝试清理它们(注意,出于类似的原因,他们也反对使用Poco模板)。由于不打算修复或改进模板,他们希望人们停止将其用于新项目,转而使用更好的替代方案:

MSDN数据库

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

STE的存在主要是为了支持实体与其上下文断开和重新连接的情况,特别是在序列化场景中(例如,WCF或Web服务)。在“标准”实体框架对象中,所有的更改跟踪都是在上下文中完成的,并且将existig实体附加到上下文是有问题的。STE使这个过程更容易,但代价是几乎所有的事情都变得很困难。

DbContext这是解决这个问题的一个更好的选择。EF的主要用户普遍认为,将EF实体端到端序列化是一个非常糟糕的想法。

用户回答回答于

我编写了可跟踪实体作为STE的替代品:https://trackable.codeplex.com。它部署为一组NuGet包和VisualStudio扩展。有一组项目模板,包括用于ASP.NETWebAPI脚手架的T4模板,以及用于生成WCF服务的项模板。

扫码关注云+社区