Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Entity Framework Self-Tracking Entities not recommended by Microsoft

While looking at Microsoft's web site, I discovered that they no longer recommend using Self-Tracking Entities.

Each link below is a MS resource that mentions not to use STEs:

  • Shows what templates are available by the Entity Framework team: EF Designer Code Generation Templates

  • Self-Tracking Entities

  • Recommended technologies for N-Tier applications

Does anyone know why Microsoft no longer recommends using STEs?

like image 750
Robert Teisanu Avatar asked Sep 17 '12 15:09

Robert Teisanu


People also ask

What's a recommended approach for using EF in disconnected applications?

Following are the two steps that needs to be taken with disconnected entity graph or even a single disconnected entity. Attach entities with the new context instance and make context aware about these entities. Set appropriate EntityStates to these entities manually.

How do you get entities back from a query without getting tracked by the context?

The AsNoTracking() extension method returns a new query and returned entities do not track by the context. It means that EF does not perform any additional task to store the retrieve entities for tracking. We can also change the default behavior of tracking at context instance level.

How do I turn off Entity Framework tracking?

In Entity Framework, change tracking is enabled by default. You can also disable change tracking by setting the AutoDetectChangesEnabled property of DbContext to false. If this property is set to true then the Entity Framework maintains the state of entities.

How do you use AsNoTracking in EF core?

The AsNoTracking() extension method returns a new query and the returned entities will not be cached by the context (DbContext or Object Context). This means that the Entity Framework does not perform any additional processing or storage of the entities that are returned by the query.


2 Answers

(NOTE: As I don't work for MS this is all conjecture based on their public statements and past history).

The first article you posted "sort of" explains the reason, though not very clearly: they want you to use a better alternative and have no intention of fixing or improving STEs. Microsoft is putting STEs into the bin of 'early failed experiments', similar to RDO or Remoting or LINQ2SQL -- they put something out to see how well it worked and it just didn't.

In general, it was always acknowledged by Microsoft that STEs were a first-stab at solving a real business problem but that they were clearly incomplete. In particular, they were really bad at attaching object graphs with shared entities, they didn't support lazy loading, and had a number of other miscellaneous limitations.

MS has apparently decided they're not going to try to clean them up (notice that they've also deprecated the POCO template, for similar reasons). Since they aren't planning to fix or improve the template, they want people to stop using it for new projects and move on to the better alternatives:

MSDN data library

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.

STEs existed mostly to support cases where entities were being disconnected and reconnected to their context, especially in serialization scenarios (WCF or web services, for example). In "standard" Entity Framework objects, all of the change tracking was done in the context, and attaching an existig entity to a context was problematic. STEs made that process easier, but at the cost of making almost everything else really hard.

From what I have seen and experienced about the DbContext it is supposed to be a better alternative to solve this problem, though it doesn't actually replicate what STEs did. The general consensus among heavy users of EF seems to be that serializing your EF entities end-to-end is a really bad idea. Instead you should be using DTOs and something like AutoMapper to map between your DTO and EF objects.

like image 97
Michael Edenfield Avatar answered Sep 30 '22 11:09

Michael Edenfield


I authored Trackable Entities as a replacement for STE's: https://trackable.codeplex.com. It's deployed as a set of NuGet packages and Visual Studio extensions. There are a set of project templates, with T4 templates for ASP.NET Web API scaffolding, as well as item templates for generating WCF services.

Here is a blog post I wrote comparing TE's with STE's: http://blog.tonysneed.com/2013/11/18/trackable-entities-versus-self-tracking-entities.

Cheers, Tony Sneed

like image 34
Anthony Sneed Avatar answered Sep 30 '22 11:09

Anthony Sneed