WCF - Falhas/Exceções versus Mensagens

Question

Atualmente estamos debatendo se é melhor lançar falhas em um canal WCF do que passar uma mensagem indicando o status ou a resposta de um serviço.

As falhas vêm com suporte integrado do WCF, onde você pode usar os manipuladores de erros integrados e reagir de acordo.Isso, no entanto, acarreta sobrecarga, pois lançar exceções no .NET pode ser bastante caro.

As mensagens podem conter as informações necessárias para determinar o que aconteceu com sua chamada de serviço sem a sobrecarga de gerar uma exceção.No entanto, são necessárias várias linhas de código repetitivo para analisar a mensagem e determinar ações após seu conteúdo.

Tentamos criar um objeto de mensagem genérico que poderíamos utilizar em nossos serviços, e foi isso que descobrimos:

public class ReturnItemDTO<T>
{
    [DataMember]
    public bool Success { get; set; }

    [DataMember]
    public string ErrorMessage { get; set; }

    [DataMember]
    public T Item { get; set; }
}

Se todas as minhas chamadas de serviço retornarem esse item, poderei verificar consistentemente a propriedade "Sucesso" para determinar se tudo correu bem.Em seguida, tenho uma sequência de mensagens de erro no evento indicando que algo deu errado e um item genérico contendo um Dto, se necessário.

As informações de exceção terão que ser registradas em um serviço de registro central e não repassadas do serviço.

Pensamentos?Comentários?Ideias?Sugestões?

Mais alguns esclarecimentos sobre minha pergunta

Um problema que estou tendo com contratos de falha é a comunicação de regras de negócios.

Tipo, se alguém fizer login e sua conta estiver bloqueada, como posso comunicar isso?O login deles obviamente falha, mas falha devido ao motivo "Conta bloqueada".

Eu também:

A) use um booleano, lance Falha com conta de mensagem bloqueada

B) retornar AuthenticatedDTO com informações relevantes

Answer 1

No entanto, isso acarreta sobrecarga, pois lançar exceções no .NET pode ser bastante caro.

Você está serializando e desserializando objetos para XML e enviando-os por uma rede lenta.a sobrecarga de lançar uma exceção é insignificante em comparação com isso.

Eu costumo me limitar a lançar exceções, já que elas comunicam claramente que algo deu errado e todos os kits de ferramentas de webservice têm uma boa maneira de lidar com eles.

No seu exemplo, eu lançaria uma UnauthorizedAccessException com a mensagem "Conta bloqueada".

Esclarecimento: Os serviços WCF do .NET traduzem exceções para FaultContracts por padrão, mas você pode alterar esse comportamento. MSDN:Especificando e tratando falhas em contratos e serviços

Answer 2

Se você pensar em chamar o serviço como chamar qualquer outro método, isso pode ajudar a colocar as coisas em perspectiva.Imagine se cada método que você chama retornasse um status e cabesse a você verificar se é verdadeiro ou falso.Seria muito tedioso.

result = CallMethod();
if (!result.Success) handleError();

result = CallAnotherMethod();
if (!result.Success) handleError();

result = NotAgain();
if (!result.Success) handleError();

Este é um dos pontos fortes de um sistema estruturado de tratamento de erros: você pode separar sua lógica real do tratamento de erros.Você não precisa ficar verificando, você sabe que foi um sucesso se nenhuma exceção foi lançada.

try 
{
    CallMethod();
    CallAnotherMethod();
    NotAgain();
}
catch (Exception e)
{
    handleError();
}

Ao mesmo tempo, ao retornar um resultado você atribui mais responsabilidade ao cliente.Você pode muito bem saber que deve verificar se há erros no objeto de resultado, mas John Doe chega e começa a ligar para o seu serviço, inconsciente de que algo está errado porque uma exceção não é lançada.Este é outro grande ponto forte das exceções: elas nos dão um bom tapa na cara quando algo está errado e precisa ser resolvido.

Answer 3

Eu consideraria seriamente usar os objetos FaultContract e FaultException para contornar isso.Isso permitirá que você transmita mensagens de erro significativas de volta ao cliente, mas somente quando ocorrer uma condição de falha.

Infelizmente, estou em um curso de treinamento no momento, então não posso escrever uma resposta completa, mas por sorte estou aprendendo sobre gerenciamento de exceções em aplicativos WCF.Vou postar de volta hoje à noite com mais informações.(Desculpe, é uma resposta fraca)