Это существующий шаблон дизайна или нет?

Question

В моей компании у нас есть проект, построенный по этой схеме. Я хотел бы знать, является ли это существующим и признанным шаблоном проектирования, комбинацией различных шаблонов или просто удобным решением проблемы кодирования.

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
    }
}

А затем в действии веб-службы:

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

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

Примечание: Я видел другие реальные проекты, следуя подобному подходу.

Answer 1

Да - он очень близок к шаблону запрос-ответ и довольно распространен в приложениях SOA или в сценариях, где вы предоставляете открытый интерфейс для внешних абонентов.

Основным преимуществом этого шаблона является то, что он очень устойчив к версии.

Обычно, если я хочу добавить новый аргумент в существующий метод интерфейса, это нарушает совместимость этого интерфейса - поскольку сигнатура метода изменилась. Клиенты, скомпилированные для одной версии, не могут вызывать другую - даже если новое поле является необязательным или старое поле устарело и может быть проигнорировано.

При использовании этого приложения сигнатура метода (ProcessRequest в вашем примере) остается прежней, но тип запроса (ConcreteRequest в вашем примере) теперь имеет дополнительное свойство. Вообще говоря, большинство сериализаций / десериализаций допускают это (или могут быть настроены так, чтобы терпеть это); если свойство появляется в данных, но не в типе, к которому оно десериализуется, оно будет проигнорировано. Conversley, если свойство не отображается в данных, но отображается в экземпляре, тогда экземпляр будет иметь значение по умолчанию (ноль, ноль или любое другое).

Таким образом, я могу добавлять / удалять параметры из метода так, как я бы не смог, если бы у меня был обычный метод со списком аргументов. По мере расширения и развития публичного интерфейса это может стать очень мощным инструментом.

Сказав все это - полезно , только если вам это нужно . Я видел его в сценариях, где это тоже не приносит никакой пользы.

Answer 2

Я думаю, что это обычно использование интерфейсов, но оно близко к Шаблон запроса-ответа . Чтобы быть лучше, вы можете использовать абстрактный фабричный шаблон или шаблон внедрения зависимостей , в зависимости от того, что вы хотите.

Answer 3

Похоже на разновидность шаблона адаптера .С точки зрения обмена сообщениями это шаблон Message Translator .

Translator Message является эквивалентом обмена сообщениями шаблона Adapter, описанного в [GoF].Адаптер преобразует интерфейс компонента в другой интерфейс, чтобы его можно было использовать в другом контексте