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?

Marj

I appreciate that this question was asked a while ago now, but I am curious as to what you ultimately decided on the POCO vs STE situation? – Freedman

Answer 1

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.

Anastassia

In ASP.NET, why not just show the STE at first request and at postback get STE from database, update the fields and save? – Sheeb

If you are happy with additional database query you don't need STE at all - except the modification of complex object graphs. You can let ObjectContext (with POCO proxies) to track changes for you. – Anastassia

"STE is useless for SOA or interoperability." I fully agree. Unfortunately people seem to insist on viewing SOA and WCF as remoting. Sure, it CAN be done, but then you are putting a lot of trust in the client. – Gutsy

While this answer is technically correct the user said nothing about SOA and is using MVC so any ViewState concerns are misplaced. – Akkadian

@jfar: Lol. That is reason for downvote? Don't you think it is a reason for clarification from Kumar? Tag says it is MVC and question is about ASP.NET 4.0 and about future extension to iPhone. Mentioning viewstate and and interoperability is fully legitimate. – Anastassia

@Ladislav Mrnka - I've reversed it. Maybe the user didn't mean to tag this with MVC. I didn't want the user to be scared of using STE's because of a technology stack he didn't use. – Akkadian

Maybe STE is not the best choise for ASP.Net scenarios, you could use DTO that is oriented to gain more decoupled solution, especially for it capabilities for interoperability (SOA) – Heelpost

Maybe it's just me, but surely the goings-on within the data access layer are confined to itself and possibly the business layer above; I'd like to think that ViewModels (or the like) are used when exposing data to layers higher up in the stack, abstracting the complexities of the data layer away from any client app or other consumers. My web apps (either ASP .Net or MVC) are completely unaware of the STE that I've used underneath as I see no sense in making a direct link in my n-tiered application from the web layer at the top straight down the data/model layers where the STEs are defined. – Freedman

Answer 2

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"

Akkadian

How are you persisting your STE between requests (eg GET --> POST)? – Sailer

@jfar, in WCF scenario the concept of "Platform Independent Services" is lost if you use STEs (a.k.a Self Tracking Entities). For example, what if there is a Java Client Application that wants to interact with the WCF service. How would the Java Client Application get the SETs at client side? Unfortunately, It simply can't! Means, if we are using STEs then our WCF service can be used only by clients built in .Net. Which is terrible isn't it? – Wiebmer

Answer 3

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)

Rubber

Answer 4

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.

Duggins