Is it recommended to use Self Tracking Entities with WCF services?

Question

I want to know if using Self Tacking Entities (in Entity Framework) is recommended with WCF services? If yes, then can you guide me to a tutorial which may guide how to do that?

Actually, I am going to develop a WPF application using Prism with MEF and MVVM. I have decided to use Entity Framework. I want suggestions and advices regarding this approach.

Any help will be appreciated.

Taproot

Answer 1

I want to know if using Self Tacking Entities (in Entity Framework) is recommended with WCF services?

It depends who you ask. If you ask MS they will tell you Yes because they simply don't have anything better to offer. STEs were response to this very old MS Connect suggestion. The problem is that EF itself has terrible bad support for merging changes between two entity graphs (you must do it completely yourselves) and developers working on MS platform (sometimes including me) share some common behaviors:

• They are lazy to develop their own solution to problem and they expect some magic directly in APIs provided by MS.
• Most of the time they are not trained / skilled / competent in the technology they have to use, because they have to move to a new one too often.
• The only APIs they know are part of .NET Framework. They don't look for other options neither they compare features.

First two points are result of MS strategy where RAD become synonym for designer (or newly also T4 templates).

I share @Richard opinion about STEs. I would add one additional drawback of STEs - they move large datasets between participants. If you decide to get an entity graph from the server, change a single entity in the graph and push data back they will transfer again the whole graph. Transferring only changed entities results in fighting with STE's core logic. I'm also afraid that they track changes completely on per entity level instead of per property level. In case of modification to entities with large binary or string data it can result in transferring too much unneeded data between the service and the database and between the service and the client.

Anyway for a simple application with low data traffic and small entities they can do a good job and allow you building your application quickly but without strict separation of concerns. You will get entities from service and bind them directly to WPF UI and they will be able to track changes for you. Later you will push entities back to service and they will be able to persist changes. Your client and service will be tightly coupled but in some scenarios it can be good enough.

Louis

Answer 2

I would avoid self tracking entities in general - I blogged about it here.

Create your own DTOs and use them to manage the transfer of data - then biuold your POCO objects in the service and use them with entity framework for persistence

If you want self tracking then there is a slightly cleaner approach here

Tyus