Is it recommended to use self-learning facilities with WCF services?

Question

I want to know if using Self Tacking Entities (in Entity Framework) using WCF services is recommended? If so, can you advise me a tutorial that can help with this?

In fact, I'm going to develop a WPF application using Prism with MEF and MVVM. I decided to use the Entity Framework. I want suggestions and advice regarding this approach.

Any help would be appreciated.

Answer 1

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

It depends on who you ask. If you ask MS, they will say yes because they simply have nothing to offer. STEs were the answer to this very old MS Connect offer . The problem is that EF itself has terrible poor support for merging changes between two entity graphs (you have to do it completely yourself) and developers working on the MS platform (sometimes including me) share some common behaviors:

• They are lazy to develop their own solution to the problem, and they expect some magic directly in the APIs provided by MS.
• In most cases, they are not trained / qualified / competent in the technology that they should use, because they have to switch to a new one too often.
• The only APIs they know are part of the .NET Framework. They do not look for other options and do not compare them.

The first two points are the result of the MS strategy, where RAD becomes a synonym for the designer (or the new T4 templates).

I share @ Richard's opinion on STE. I would add another drawback to STEs - they move large datasets between participants. If you decide to get the object graph from the server, change the single object in the graph and return the data back, they will again transfer the entire graph. Transferring only modified objects leads to a struggle with the basic STE logic. I also fear that they fully track changes at the entity level instead of ownership level. If you modify objects with large binary or string data, this can lead to the transfer of too much unnecessary data between the service and the database, as well as between the service and the client.

In any case, for a simple application with low data traffic and small objects, they can do a good job and allow you to quickly create an application, but without a strict separation of problems. You will get the objects from the service and attach them directly to the WPF interface, and they will be able to track the changes for you. You will push entities to service later, and they will be able to save changes. Your client and service will be closely connected, but in some scenarios this can be quite good.

Answer 2

I would generally avoid self-examining objects - I wrote about it here .

Create your own DTOs and use them to control the transfer of data - then biuold your POCO objects in the service and use them with the entity infrastructure to store

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