Question

In my company, we have a project built upon this pattern. I would like to know if this is an existing and acknowledged design pattern, a combination various patterns or just a convenient coding solution to a problem.

interface IService <TRequest, TResponse>
    where TRequest : IRequest, TResponse : IResponse
{
     TResponse ProcessRequest(TRequest request);
}

public class ConcreteService : IService<ConcreteRequest, ConcreteResponse>
{
    public ConcreteResponse ProcessRequest(ConcreteRequest request)
    {
        // Do some stuff to create the ConcreteResponse object
    }
}

And then in a web service action:

[WebMethod]
public ConcreteResponse SomeService(ConcreteRequest request)
{
    // Do some validations...

    // And then...
    var service = new ConcreteService();
    return service.ProcessRequest(request);
}

Note: I have seen other real world projects following a similar approach.

Answer 1

Yes – it is very close to the Request-Response pattern and it is quite common in SOA applications, or in scenarios where you present a public interface to external callers.

The main advantage to this pattern is that it is highly version tolerant.

Normally, if I want to add a new argument to an existing method on an interface, it breaks the compatibility of that interface – because the signature of the method has changed. Clients compiled against one version, cannot call another – even if the new field is optional, or if an old field has been obsoleted and can be ignored.

Using this apporach, the signature of the method (ProcessRequest in your example) itself stays the same, but the request type (ConcreteRequest in your example) now has an additional property on it. Generally speaking most serialization/deserialization is tolerant of this (or can be configured to be tolerant of this); if the property appears in the data but not on the type it is being deserialized to, it will be ignored. Conversley if the property doesn’t appear in the data, but does on the instance then the instance will just have a default value (null, zero or whatever).

So I can add/remove parameters from the method in a way that I wouldn’t be able to do if I had a normal method with a list of arguments. As you extend and evolve a public interface, this can become a very powerful tool.

Having said all of that – it is only useful if you need it. I’ve seen it used in scenarios where this brings no benefit too.