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?
+5
A:
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 loose 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"
jfar
2010-09-28 18:10:52
+9
A:
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.
Ladislav Mrnka
2010-09-28 18:39:28
In ASP.NET, why not just show the STE at first request and at postback get STE from database, update the fields and save?
Fujiy
2010-09-28 18:44:14
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.
Ladislav Mrnka
2010-09-28 18:49:39
"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.
Daniel Auger
2010-09-28 19:09:27
While this answer is technically correct the user said nothing about SOA and is using MVC so any ViewState concerns are misplaced.
jfar
2010-09-28 19:24:33
@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.
Ladislav Mrnka
2010-09-28 19:36:49
@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.
jfar
2010-09-28 22:24:39
+1
A:
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.
Wyatt Barnett
2010-09-28 21:07:15