问题
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?
回答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.
回答2:
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
来源：https://stackoverflow.com/questions/12462319/entity-framework-self-tracking-entities-not-recommended-by-microsoft