Self Tracking Entities vs POCO Entities

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.

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"

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)