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应用程序中或在向外部调用者提供公共接口的情况下非常常见。

这种模式的主要优点是它具有高度版本容忍度。

通常，如果我想在接口上为现有方法添加新参数，则会破坏该接口的兼容性 - 因为方法的签名已更改。针对一个版本编译的客户端不能调用另一个版本 - 即使新字段是可选的，或者旧字段已经过时且可以忽略。

使用此apporach，方法的签名（示例中为ProcessRequest）本身保持不变，但请求类型（示例中为ConcreteRequest）现在有一个附加属性。一般来说，大多数序列化/反序列化都可以容忍这种情况（或者可以配置为容忍这种情况）;如果属性出现在数据中但未出现在被反序列化的类型上，则将忽略该属性。 Conversley如果属性没有出现在数据中，但是在实例上然后实例将只有一个默认值（null，零或其他）。

所以我可以用一种方法添加/删除方法中的参数，如果我有一个带有参数列表的普通方法，我将无法做到这一点。随着您扩展和发展公共界面，这可以成为一个非常强大的工具。

说完所有这些 - 如果你需要它只会有用。我已经看到它用于那些也没有带来任何好处的场景。

Answer 2

它似乎是各种Adapter pattern。在消息传递方面，这是Message Translator模式。

Message Translator是Adapter的消息传递 [GoF]中描述的模式。适配器转换a的接口组件进入另一个接口，因此可以在不同的地方使用上下文

Answer 3

我认为这是接口的正常用法，但接近Request-Response pattern。为了更好，您可以使用an abstract factory pattern或dependency injection pattern，具体取决于您的需求。

这是现有的设计模式吗？

3 个答案: