Question

Is it ok from your real-world-experience to define service contract with one method which will accept some object as a form of request and return some other object as a result of that request. What I mean is instead of having method for creating, deleting, editing and searching customers I would have these activities encapsulated within DataContracts and what service would do after receiving such DataContract would be take some action accordingly. But service interface would be simple as that:

interface ISomeService
{
  IMessageResult Process(IMessageRequest msg);
}

So IMessageRequest would have filed named OperationType = OperationTypes.CreateCustomer and rest of fields would provide enough information for the service that it could create Customer object or record in database or whatever. And IMessageResult could have field with some code for indication that customer was created or not.

What I’m trying to achieve by such design is an ability to easy delegate IMessageRequest to other internal services that client side wouldn’t even know about. Another benefit I see is that if we will have to add some operation on customers we only provide additional DataContract for this operation and don’t have to change anything on service interface side (I want to avoid this at all costs, I mean not new operations but changing service interface 🙂

So, what do you think? Is it good way of handling complicated business processes? What are pitfals, what could be better.

If I duplicated some other thread and there are some answers to my question please provide me with links because I didn’t find them.

Answer 1

Short answer: yes, this could be a very good idea (and one I have implemented in one form or another a couple of times).

A good starting point for this type of approach are the posts by Davy Brion on what he calls the request/response layer. He consolidated his initial ideas & thoughts into a very usable OSS project called Agatha, which I am proposing at a customer site as I write this.