这是一个现有的设计模式吗？

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

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

- Meryovi

---

我看到了一些继承和泛型，但是我不知道你可能在考虑哪种模式。 - Oded

没有实际的代码或解释说明其预期功能，这看起来很像经典的“过度设计”模式。 - Fred Foo

@larsmans - 我猜这种方法更多地与为外部客户提供版本容差有关。 - Rob Levine

@larsmans 它被用于一个Web服务项目中，用来创建适当的响应以回应用户发出的任何请求。我们为Web服务中的每个Web方法（20多个Web方法）都有一个继承自IService的类，这样做是为了将逻辑保持在Web服务之外。 - Meryovi

Answer 1

是的-它非常接近请求-响应模式，并且在SOA应用程序或呈现公共接口给外部调用者的场景中很常见。

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

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

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

因此，我可以以我无法使用带有参数列表的普通方法的方式添加/删除方法中的参数。随着扩展和发展公共接口，这可能成为一个非常强大的工具。

话虽这样，仅当您需要它时才会有用。我曾经看到它在不带来任何好处的情况下使用。

- Rob Levine

---

请求/响应模式仅描述了在SOA中使用这两个对象交换信息，还是它也涉及这些对象相互交互和它们的生命周期的方式？ - Meryovi

从记忆中 - 我会说它描述了这样一个想法，即您有一个单一的 "ProcessRequest" 方法，并通过不同的具体类型进行传递。您可以拥有一个具有相应的 GetUserInfoResponse 和一个具有相应的 DeleteUserResponse 的 GetUserInfoRequest 和 DeleteUserRequest。然后，您所有的调用都要经过一个方法，但具体的请求类型决定了实际的调用本身。如上所述，请求/响应对象随着时间的推移也可以更改而不会破坏一切。您还可以添加新的 "方法"，而无需更改公共方法签名，只需更改其接受的类型即可。 - Rob Levine

Answer 2

这似乎是一种适配器模式的变体。在消息传递方面，这就是一种消息翻译器模式。

消息翻译器是与适配器模式相当的消息传递模式，如[GoF]所述。适配器将组件的接口转换为另一个接口，以便在不同的上下文中使用。

- sll

---

我同意这是一个消息翻译器，但前提是// Do some stuff to create the ConcreteResponse object只是一些简单的代码，可以被视为仅进行翻译。 - DaveFar

是的，你说得对。但从另一个角度来看，我们可以把这个称作“服务作为消息转换器”，它将请求转换成响应。但这不仅仅是关于消息转换，更多地涉及面向服务架构（SOA），所以我承认"消息转换器"在这个例子中不太适合。 - sll

@DaveBall 可能 ProcessRequest 方法具有复杂的逻辑。这不是从请求到响应的简单转换。 - Meryovi

Answer 3

我认为这是接口的常规用法，但它接近于请求-响应模式。为了更好地实现，您可以使用抽象工厂模式或依赖注入模式，具体取决于您想要什么。

- Vinicius Ottoni

---

你能解释一下另外两种模式在这种情况下如何使代码“更好”吗？ - svick

第一个，根据他的目标，他想要多少种具体的响应类型，这可能很有用。第二个是将接口“翻译”为具体类，例如使用企业库Unity，在一个地方仅更改“翻译”，甚至在创建新对象时像转换一样手动更改所有使用“手动”翻译的类。 - Vinicius Ottoni