EF4 + STE: Reattaching via a WCF Service? Using a

Question

I am planning to use WCF (not ria) in conjunction with Entity Framework 4 and STE (Self tracking entitites). If i understnad this correctly my WCF should return an entity or collection of entities (using LIST for example and not IQueryable) to the client (in my case silverlight)

The client then can change the entity or update it. At this point i believe it is self tracking???? This is where i sort of get a bit confused as there are a lot of reported problems with STEs not tracking..

Anyway... Then to update i just need to send back the entity to my WCF service on another method to do the update. I should be creating a new OBJECTCONTEXT everytime? In every method?

If i am creaitng a new objectcontext everytime in everymethod on my WCF then don't i need to re-attach the STE to the objectcontext?

So basically this alone wouldn't work??

using(var ctx = new MyContext())
{
    ctx.Orders.ApplyChanges(order);
    ctx.SaveChanges();
}

Or should i be creating the object context once in the constructor of the WCF service so that 1 call and every additional call using the same wcf instance uses the same objectcontext?

I could create and destroy the wcf service in each method call from the client - hence creating in effect a new objectcontext each time.

I understand that it isn't a good idea to keep the objectcontext alive for very long.

Any insight or information would be gratefully appreciated

thanks

Answer 1

You can attach an entity to a new object context, see http://msdn.microsoft.com/en-us/library/bb896271.aspx.

But, it will then have the state unchanged.

The way I would do it is:

• to requery the database for the information
• compare it with the object being sent in
• Update the entity from the database with the changes
• Then do a normal save changes

Edit

The above was for POCO, as pointed out in the comment

For STE, you create a new context each time but use "ApplyChanges", see: http://msdn.microsoft.com/en-us/library/ee789839.aspx

Answer 2

You are asking several questions so I will try to answer them separately:

Returning IQueryable:

You can't return IQueryalbe. IQueryable describes query which should be executed. When you try to return IQueryable from service it is being executed during serialization of service response. It usually causes exception because ObjectContext is already closed.

Tracking on client:

Yes STEs can track changes on a client if client uses STEs! Assembly with STEs should be shared between service and client.

Sharing ObjectContext:

Never share ObjectContext in server environment which updates data. Always create new ObjectContext instance for every call. I described reasons here.

Attaching STE

You don't need to attach STE. ApplyChanges will do everything for you. Also if you want to returen order back from your service operation you should call AcceptChanges on it.

Creating object context in service constructor:

Be aware that WCF has its own rules how to work with service instances. These rules are based on InstanceContextMode and used binding (and you can implement your own rules by implement IInstanceProvider). For example if you use BasicHttpBinding, default instancing will be PerCall which means that WCF will create new service instance for each request. But if you use NetTcpBinding instead, default instancing will be PerSession and WCF will reuse single service instance for all request comming from single client (single client proxy instance).

Reusing service proxy on a client:

This also depends on used binding and service instancing. When session oriented binding is used client proxy is related to single service instance. Calling methods on that proxy will always execute operations on the same service instance so service instance can be stateful (can contains data shared among calls). This is not generally good idea but it is possible. When using session oriented connection you have to deal with several problems which can arise (it is more complex). BasicHttpBinding does not allow sessions so even with single client proxy, each call is processed by new service instance.