.net - 这是否是现有的设计模式？

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

然后在 Web 服务操作中:

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

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

注意:我见过其他现实世界的项目采用了类似的方法。

Answer 1

是的 - 它非常接近请求-响应模式，并且在 SOA 应用程序或向外部调用者提供公共(public)接口(interface)的场景中非常常见。

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

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

使用此方法，方法的签名(在您的示例中为 ProcessRequest)本身保持不变，但请求类型(在您的示例中为 ConcreteRequest)现在具有附加属性。一般来说，大多数序列化/反序列化都可以容忍这个(或者可以配置为容忍这个)；如果属性出现在数据中，但不在反序列化到的类型上，它将被忽略。 Conversley 如果属性没有出现在数据中，但出现在实例上，那么实例将只有一个默认值(null、零或其他)。

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

说了这么多——它只有在你需要的时候才有用。我已经看到它在没有任何好处的情况下使用。