Question

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?

Answer 1

(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.