WCF - Fallas / Excepciones frente a los Mensajes

Question

Actualmente estamos teniendo un debate de si es mejor tirar las faltas más de un canal WCF, pasando frente a un mensaje que indica el estado o la respuesta de un servicio.

Los fallos vienen con soporte integrado de WCF donde se puede utilizar el built-in de los controladores de error y actuar en consecuencia.Esto, sin embargo, lleva a la sobrecarga de como lanzar excepciones .NET puede ser muy costoso.

Los mensajes pueden contener la información necesaria para determinar qué pasó con su servicio de llamadas sin la sobrecarga de lanzar una excepción.No obstante, se necesitan varias líneas de código repetitivo para analizar el mensaje y determinar las acciones siguientes de su contenido.

Nos tomó una puñalada en la creación de un mensaje genérico de objetos podemos utilizar en nuestros servicios, y esto es lo que ocurrió:

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

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

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

Si todos mis llamadas de servicio de devolución de un artículo, yo siempre se puede comprobar el "Éxito" de la propiedad para determinar si todo ha ido bien.Tengo una cadena de mensaje de error en el caso de indicar que algo salió mal, y la genérica de un elemento que contiene un Dto si es necesario.

La excepción de la información tendrá que ser conectado a una central de servicio de registro y no pasa de el servicio.

Los pensamientos?Comentarios?Ideas?Sugerencias?

Algunas aclaraciones sobre mi pregunta

Un problema que estoy teniendo con la culpa de los contratos es la comunicación de reglas de negocio.

Igual, si alguien se registra, y su cuenta está bloqueada, ¿cómo me comunico que?Su inicio de sesión evidentemente no, pero falla debido a la razón "Cuenta Bloqueada".

Por lo que hago:

A) utilizar un valor booleano, tirar de Falla con el mensaje de la cuenta bloqueada

B) la devolución AuthenticatedDTO con la información pertinente

Answer 1

Sin embargo, esto lleva a la sobrecarga de como lanzar excepciones .NET puede ser muy costoso.

Estás serializar y de serializar objetos a XML y el envío de ellos a través de una red lenta..la sobrecarga de lanzar una excepción es negligable en comparación con eso.

Me suelen ceñirse a lanzar excepciones, ya que claramente comunicar algo salió mal y todos webservice kits de herramientas de tener un buen manejo de ellos.

En su muestra, me gustaría lanzar una UnauthorizedAccessException con el mensaje "Cuenta Bloqueada".

Aclaración: El .RED de servicios wcf traducir excepciones a FaultContracts por defecto, pero usted puede cambiar este comportamiento. MSDN:Especificación y Manejo de Fallas en Contratos y Servicios

Answer 2

Si usted piensa acerca de llamar al servicio como llamar a cualquier otro método, puede ayudar a poner las cosas en perspectiva.Imagínese si cada método se llama devuelve un estado, y que era a usted a comprobar si era cierto o falso.Sería muy 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 una estructura de error del sistema de gestión, es que usted puede separar su propia lógica de su manejo de errores.Usted no tiene que mantener el control, sabes que fue un éxito, si no se producía ninguna excepción.

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

Al mismo tiempo, devolviendo un resultado que usted está poniendo más responsabilidad en el cliente.Usted puede conocer perfectamente para comprobar errores en el objeto de resultado, pero John Doe viene y empieza a llamar de inmediato a su servicio, olvidándose de que algo está mal debido a una excepción no es lanzada.Este es otro gran fuerza de las excepciones es que nos den una buena bofetada en la cara cuando algo está mal y necesita ser cuidado.

Answer 3

Debería considerar seriamente el uso de la FaultContract y FaultException objetos para conseguir alrededor de esto.Esto le permitirá pasar mensajes de error significativos para el cliente, pero sólo cuando ocurre una falla.

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