WCF: fallas/excepciones versus mensajes

exception

Question

Actualmente estamos debatiendo si es mejor lanzar fallas sobre un canal WCF, en lugar de pasar un mensaje que indique el estado o la respuesta de un servicio.

Las fallas vienen con soporte integrado de WCF donde usted puede usar los manejadores de errores incorporados y reaccionar en consecuencia. Esto, sin embargo, conlleva gastos generales, ya que arrojar excepciones en .NET puede ser bastante costoso.

Los mensajes pueden contener la información necesaria para determinar qué sucedió con su llamada de servicio sin la sobrecarga de lanzar una excepción. Sin embargo, necesita varias líneas de código repetitivo para analizar el mensaje y determinar las acciones que siguen a su contenido.

Apuntamos a crear un objeto de mensaje genérico que pudiéramos utilizar en nuestros servicios, y esto es lo que se nos ocurrió:

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

Si todas mis llamadas de servicio devuelven este artículo, puedo verificar consistentemente la propiedad "Correcto" para determinar si todo salió bien. Luego tengo una cadena de mensaje de error en el evento que indica que algo salió mal, y un elemento genérico que contiene un Dto si es necesario.

La información de excepción tendrá que ser desconectada a un servicio de registro central y no retransmitida desde el servicio.

¿Pensamientos? ¿Comentarios? Ideas? Sugerencias?

Algunas aclaraciones adicionales sobre mi pregunta

Un problema que estoy teniendo con los contratos de falla es comunicar las reglas comerciales.

Por ejemplo, si alguien inicia sesión y su cuenta está bloqueada, ¿cómo la comunico? Su inicio de sesión obviamente falla, pero falla debido a la razón "Cuenta bloqueada".

Yo también:

A) usar un booleano, arrojar una falla con la cuenta de mensaje bloqueada

B) devuelve AuthenticatedDTO con información relevante

Answer 1

Sin embargo, esto conlleva gastos generales, ya que arrojar excepciones en .NET puede ser bastante costoso.

Estás serializando y deserializando objetos a XML y enviándolos a través de una red lenta ... la sobrecarga de lanzar una excepción es insignificante en comparación con eso.

Por lo general, me atengo a arrojar excepciones, ya que claramente comunican que algo salió mal y que todos los kits de herramientas del servicio web tienen una buena manera de manejarlos.

En su ejemplo, lanzaría una Access Access no autorizada con el mensaje "Cuenta bloqueada".

Aclaración: los servicios wcf de .NET traducen excepciones a FaultContracts de manera predeterminada, pero puede cambiar este comportamiento. MSDN: Especificación y manejo de fallas en contratos y servicios

Answer 2

Consideraría seriamente usar los objetos FaultContract y FaultException para evitar esto. Esto le permitirá pasar mensajes de error significativos al cliente, pero solo cuando ocurra una falla.

Lamentablemente, estoy en un curso de capacitación por el momento, por lo que no puedo escribir una respuesta completa, pero por suerte, estoy aprendiendo acerca de la administración de excepciones en las aplicaciones de WCF. Voy a publicar esta noche con más información. (Lo siento es una respuesta débil)

Answer 3

Si piensa en llamar al servicio como si llamara a cualquier otro método, puede ayudar a poner las cosas en perspectiva. Imagine si cada método que llamó devuelve un estado, y usted depende de usted para verificar si es verdadero o falso. Sería bastante tedioso.

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

Este es uno de los puntos fuertes de un sistema estructurado de manejo de errores, es que usted puede separar su lógica real del manejo de errores. No tiene que seguir revisando, sabe que fue un éxito si no se emitió ninguna excepción.

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

Al mismo tiempo, al devolver un resultado, está asignando más responsabilidades al cliente. Es probable que sepa verificar los errores en el objeto de resultado, pero John Doe entra y simplemente comienza a llamar a su servicio, sin darse cuenta de que algo está mal porque no se lanza una excepción. Esta es otra gran fortaleza de las excepciones: nos dan una buena bofetada cuando algo está mal y hay que ocuparse de ello.