Self Tracking Entities vs POCO Entities

Question

We are starting a new web based product in which we are planning to expose our business logic through WCF services. We will be using ASP.NET 4.0, C#, EF 4.0. In future we want to build iphone applications and WPF applications based on the services. I have been reading a lot about using POCO vs Self Tracking Entities (STE) and from my understand the STEs do not work well with the web scenario. Can anyone shed more light on this issue?

Answer 1

Self Tracking Entities work perfectly in a MVC Web with WCF scenario. I've been involved in 2 projects using them ( one in production, one almost ).

With POCOs you'd lose any change tracking over the wire which creates a lot of extra pain because EF now has to re-query for state information. If your using EF and WCF STE's solve a lot of problems and make your entire persistence pipeline really smooth.

---

Can you provide citation for this claim? "STEs do not work well with the web scenario"

Answer 2

For me STE is absolutely wrong concept. It is just another implementation of DataSet.

• In ASP.NET application you will have to store STEs somewhere among requests. In first request you will query your datasource to get STE and provide data in the page. In the next request (postback) you will want to modify STE with returned data from the browser. To support tracking you will have to use the same STE as in the first request => you will have to store STE in viewstate (if you want to use ASP.NET WebForms) or session.
• STE is useless for SOA or interoperability. Tracking logic is part of STE = it is running on the client. If you expose STE in the service you are immediatelly expecting that client side will use the same tracking features included in STE logic. But these features are not provided to other side automatically. In .NET you have them because you share assembly with STEs. But on other platform you have to explain developers how to implement STE logic to make it work on your side. This will be probably the most limiting case for you because of iPhone application.

Answer 3

If this service is going to be consumed by any app you don't have direct control over, you should probably strongly consider divorcing anything to do with EF (or nHibernate or Linq2Sql or any other data persistence management solution) from your services and your data transfer objects. This will insulate internal changes from breaking clients. Breaking clients is typically a bad thing.

Answer 4

Refer to http://msdn.microsoft.com/en-us/data/jj613924.aspx, as STEs is No Longer Recommended! Microsoft recommends using any of ASP.NET Web API, WCF Data Services, or Entity Framework APIs (complex ops)