Home/ Questions/Q 6744871
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T12:08:08+00:00

Since I asked How has to be written the signature in facade pattern? question,

  • 0

Since I asked How has to be written the signature in facade pattern? question, I’ve thought about how to create a signature for an API that has to be both useful and efficient (and a aesthetically nice solution!) . I’ve seen some APIs and their boundary interfaces at the top expose the following style of signature:

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

In this style, business rules violations and other normal/abnormal business situations had to be reported using an specific exception designed for this signature or adopting some convention like returning nulls to state the situation at the end of method’s execution.

I think that to use exceptions to show business problems can lead to maintainability problems and it surely is a bad practice (there is a bunch of technical bibliography arguing about this). So, to cope with this problems I suggest to use an structure or a class like this:

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

enum Status {SUCCESS, FAILURE, ANY_OTHER_STATUS};

the former signature can then be written like:

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

Where all interesting things for any consuming layers can be known, at least, efficiently. Notice that there are not exceptions to control flow (except probably for those you want outer layers to know), and business layer can have the entire control about business error messages. Do you think this approach has any flaw?

Please, if possible, add some bibliography for your answer.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We pretty much use the same throughout our enterprise apps, with two additions, viz 1) for transactional services, an additional List<> property containing a list of “Validation Results”, each of which models a single business rule or validation rule violation, which can then be reported back to the client (user or service consumer) with as much context information as possible, and 2) for data services we add paging information, indicating how much total data is available to the client (given that we only allow a finite number of rows to be returned). This allows the client to tie into a pagination strategy.

    The only complaint thus far is for Service Consumers – when we exposed service methods returning the typed generic across the enterprise (ESB / SOA), is that the WSDL / naming of the generics can be cumbersome (e.g. ReturnResultOfPOUpdateRequestJQ3KogUE). This isn’t of much concern to .NET clients if we share the Entities on both client and service, but for other clients such as Java, Mobile etc can be problematic, and sometimes we need to provide an alternative facade for such clients without the generics.

    • 0