views:

43

answers:

1

First of all, this is my first Stack Overflow question so apologies in advance if I get this wrong!

I'm working on creating a service endpoint for a CRM database used internally. Several applications want to read and write to this database so exposing a WCF service seemed like the best approach.

I started off using the Entity Framework for ORM, CSLA for the Business Logic layer and a standard WCF service for communication with the client applications. All was going fine until I took a look at WCF Data Services and got seduced by the lovely REST interface, ease of consumption by AJAX clients and the joy of using new tech!

I've now replaced large parts of the WCF services with a single WCF Data Service which exposes the Entity Framework model directly, bypassing the CSLA layer. This works great for read only operations but I cannot perform the other CRUD functions without some business logic.

I've been looking into Interceptors and I can certainly put business login in there but I actually want to intercept the POST/Add operation, map the values onto the CSLA BusinessBase class in question and let that do all the validation and final save into the database. I've tried this and while the CSLA object works as intended, the underlying WCF Data Service framework also persists its version so I get two entries in the db.

I therefore have a few questions:

1) Can I completely intercept a Change request, let my own business objects handle it then cancel the WCF Data Service without throwing an exception?

2) Is there a better/standard approach to adding business logic layers to a WCF Data Service stack? I have not been able to find one so far.

Thanks in advance,

Dave

+1  A: 

Unfortunately if the underlying provider for WCF Data Services is Entity Framework you can't do it all on your own. Currently we don't support completely replacing parts of the processing pipeline in this case. On the other hand you might be able to play some tricks. You can do this mostly on the entity framework. The latest version of EF should let you override the SaveChanges call such that you get to do whatever you want there. So the idea would be that you handle the Add operation in your change itnerceptor on your own and then in SaveChanges you revert the change created by WCF Data Services and only submit the change from your change interceptor. Or maybe even better, just do everything in the SaveChanges. There might be other nice tricks to play with EF which WCF Data Services might just use without knowing, but I'm no EF expert to tell for sure. Currently interceptors are the standard way to layer business logic into WCF Data Services (which works for any provider including EF). The other way to do this would be to move away from REST a little bit. You could disallow POST requests to the given entity set (you can throw from your change interceptor) and add a service operation to perform the add in your own code. In that case you would have full control, but clients would be a bit harder to get working.

Vitek Karas MSFT