Entity Framework Self-Tracking Entities not recommended by Microsoft

.net c# entity-framework self-tracking-entities

Question

I found out that Microsoft no longer advises utilizing Self-Tracking Entities when browsing their website.

The MS resources listed below each provide a warning not to use STEs:

Anyone know the reason why Microsoft no longer advises utilizing STEs?

1
18
9/17/2012 3:25:14 PM

Accepted Answer

(NOTE: Since I don't work for Microsoft, all of this is based on their prior behavior and public pronouncements.)

Although it's not stated very explicitly, the first article you uploaded "kind of" explains why: they want you to use a better substitute and have no plan of repairing or enhancing STEs. Similar to RDO, Remoting, and LINQ2SQL, Microsoft is classifying STEs as "early failed experiments" since they released something to test its viability but it ended up failing.

In general, Microsoft always admitted that STEs were an attempt to address a genuine business issue, but that they were obviously deficient. They were particularly bad at connecting object graphs with shared entities, didn't allow lazy loading, and had a variety of other flaws.

MS seems to have made the decision that they won't attempt to clean them up (note how they also deprecated the POCO template for related reasons). They encourage users to cease using the template for new projects and move on to the better alternatives since they don't have any plans to modify or upgrade it:

MSDN data repository

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.

Particularly in serialization situations, STEs were primarily designed to handle circumstances when things were being separated from and then reunited to their environment (WCF or web services, for example). All change tracking in "ordinary" Entity Framework objects took place in the context, making it difficult to tie an existing entity to a context. STEs facilitated that process, but at the expense of making almost everything else very difficult.

based on what I have seen and experienced, theDbContext It doesn't truly accomplish what STEs did, but it is claimed to be a superior solution to this issue. Heavy EF users seem to agree that serializing EF entities end-to-end is a terrible idea in general. Instead, you need to map between your DTO and EF objects using DTOs and something like AutoMapper.

12
12/25/2012 7:48:53 AM

Popular Answer

As an alternative to STEs, I created Trackable Entities: https://trackable.codeplex.com. It is made available as a collection of Visual Studio extensions and NuGet packages. A collection of project templates is available, including item templates for creating WCF services and T4 templates for constructing ASP.NET Web APIs.

I compared TEs with STEs in this blog post: http://blog.tonysneed.com/2013/11/18/trackable-entities-versus-self-tracking-entities.

Cheers, Nick Sneed



Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow