self-tracking-entities

Reading the msdn information on EF 5.0 and n-tier solutions see link , it seems that MS is not recommending STE's and the POCO/DTO way is also not recommended by stating that it is difficult. Not all (perhaps not many?) applications are suited for using WCF Data Services. So what is the way to go? My scenario is a current, large server (WebServices) application with many clients (only our own), mostly WinForms. Today DataSets are used to ship the data and track changes into the SQL Server database. We are now starting to replace WebServices with WCF and are also looking into using the Entity

I have to recalculate values on a large collection of entities, one after the other. During that process, all the self-tracking-entities are altered within the same ObjectContext. For each entity that needs to be processed, small amounts of data has to be fetched from the database. That results in a lot of the same SQL query but using different parameters. I am using Solutions Design's ORM Profiler software to profile the queries that are sent to the database. The queries themselves seems okay to me. They are short and don't take much time to execute. However, I am confused about how the

I have a client application that downloads a number of STE's via WCF. Using a WPF application, users can select an entity from a ListBox, and edit it via a popup UserControl. As the UserControl is bound directly to the object, when a user makes a change it of course affects the object. I would like to provide a Cancel function which will undo all changes made to the entity. Any thoughts? You can keep a original copy of the entity. And edit a cloned version of it. If the user cancels the changes you simply keep using the original copy. I would say as you use WPF just in binded PropertyChanged

I'm trying to ramp up on the entity framework so I don't feel like I'm in the dark ages. I tried (and have thus far failed) to intuit from generated code what the essential differences between the available code generation items. It seems POCO isolates the entity data structures from the ojbect that moves them in/out of a datastore. I'm not sure what a "Self-Tracking Entity" is. I'm guessing the tracking part refers realizing the so called "unit of work" pattern, but I'm not posative. And more head scratchingly, I guess I'm wondering "self tracking as opposed to what?". Ladislav Mrnka POCO

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? Michael Edenfield (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,

Developing n-layered application with DDD (o better DDDD because we are using WCF) using Microsoft technology (where we have full controll of all component), the best choise seems to be STE vs POCO (this last one force the usage of DTOs). That's right? In your opinion make sense the usage of STE with DTOs where we need them? Thanks. I really can recommend Julie Lerman's Programming Entity Framework . She goes in depth about simple poco's, dto's and Self Tracking Entities. Advantages and disadvantages are described. But off course depending a lot on application requirements and personal taste.

I am using EF4 Self Tracking Entities (VS2010 Beta 2 CTP 2 plus new T4 generator). But when I try to update entity information it does not update to database as expected. I setup 2 service calls. one for GetResource(int id) which return a resource object. the second call is SaveResource(Resource res); here is the code. public Resource GetResource(int id) { using (var dc = new MyEntities()) { return dc.Resources.Where(d => d.ResourceId == id).SingleOrDefault(); } } public void SaveResource(Resource res) { using (var dc = new MyEntities()) { dc.Resources.ApplyChanges(res); dc.SaveChanges(); //