CODEWITHSUNDEEP
.netoopdesign-patterns
Meryovi
Meryovi

Reputation: 6231

Is this an existing design pattern or not?

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.

Upvotes: 3

Views: 172

Answers (3)

Vinicius Ottoni
Vinicius Ottoni

Reputation: 4677

I think this a normally usage of interfaces, but it's close to Request-Response pattern. To be better, you can use an abstract factory pattern or dependency injection pattern, depends on what you want.

Upvotes: 2

sll
sll

Reputation: 62484

It seems like a variety of the Adapter pattern. In terms of messaging this is a Message Translator pattern.

The Message Translator is the messaging equivalent of the Adapter pattern described in [GoF]. An adapter converts the interface of a component into a another interface so it can be used in a different context

Upvotes: 2

Rob Levine
Rob Levine

Reputation: 41298

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.

Upvotes: 4

Related Questions