Question

自从我问How has to be written the signature in facade pattern?问题以来，我一直在思考如何为API创建一个必须既有用又高效的签名（以及一个美观的解决方案！）。我已经看到一些API及其顶部的边界接口暴露了以下签名样式：

public List<InterestingDTO> 
    ANecessaryMethodToCompleteABusinessProcess(int aParameter, 
    InterestingDTO aSecondParamenter)

在这种风格中，必须使用为此签名设计的特定异常报告业务规则违规和其他正常/异常业务情况，或者采用一些约定，例如返回空值以在方法执行结束时说明情况。

我认为使用例外来显示业务问题会导致可维护性问题，这肯定是一种不好的做法（有很多技术参考书目在争论这个问题）。所以，为了解决这个问题，我建议使用这样的结构或类：

public class ReturnValue<T>
{
    public T returnedValue;
    public string message;
    public Status status;    
}

enum Status {SUCCESS, FAILURE, ANY_OTHER_STATUS};

以前的签名可以写成：

 public ReturnValue<List<InterestingDTO>> 
        ANecessaryMethodToCompleteABusinessProcess(int aParameter, 
        InterestingDTO aSecondParamenter)

至少可以有效地了解任何消费层的所有有趣事物。请注意，控制流没有例外（可能除了您希望外层知道的那些），业务层可以完全控制业务错误消息。你觉得这种方法有什么缺陷吗？

如果可能的话，请为您的答案添加一些参考书目。

Answer 1

我们在整个企业应用程序中几乎都使用相同的功能，有两个附加功能，即1）用于事务性服务，另外一个List＆lt;＆gt;包含“验证结果”列表的属性，每个属性都模拟单个业务规则或验证规则违规，然后可以使用尽可能多的上下文信息将其报告给客户端（用户或服务使用者），以及2）数据服务我们添加了分页信息，表明客户端可用的总数据量（假设我们只允许返回有限数量的行）。这允许客户端与分页策略相结合。

迄今为止唯一的抱怨是服务使用者 - 当我们公开在整个企业中返回类型化通用的服务方法（ESB / SOA）时，泛型的WSDL /命名可能很麻烦（例如ReturnResultOfPOUpdateRequestJQ3KogUE）。如果我们在客户端和服务上共享实体，这对.NET客户端来说并不是很重要，但对于其他客户端，例如Java，Mobile等可能会有问题，有时我们需要为这些客户端提供替代外观，而不需要泛型。

从Facade签名返回包含所有重要返回值的通用对象是否合适？

1 个答案: