最好返回一个通用对象，其中包含来自facade签名的所有重要返回值

Question

既然我问如何在facade模式中编写签名?问:我想过如何为API创建一个既有用又高效的签名(而且是一个美观的解决方案!)我见过一些api及其顶部的边界接口暴露了以下风格的签名:

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

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

我认为使用异常来显示业务问题可能会导致可维护性问题，这肯定是一个不好的做法(有一堆技术参考文献对此争论不休)。因此，为了解决这个问题，我建议使用这样的结构或类:

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 <>属性包含一个"验证结果"列表，每个列表都建模一个业务规则或验证规则违规，然后可以将尽可能多的上下文信息报告给客户端(用户或服务消费者)，以及2)对于数据服务，我们添加分页信息。指示客户机可用的总数据量(假设我们只允许返回有限数量的行)。这允许客户端绑定到分页策略。

到目前为止，唯一的抱怨是服务消费者——当我们在整个企业(ESB/SOA)中公开返回类型化泛型的服务方法时，泛型的WSDL/命名可能很麻烦(例如ReturnResultOfPOUpdateRequestJQ3KogUE)。如果我们在客户端和服务上共享实体，这对。net客户端来说不是太重要，但对于其他客户端，如Java、Mobile等，可能会有问题，有时我们需要为这些客户端提供一个没有泛型的替代facade。