Pregunta

Tengo un SVC WCF separa en una capa de servicios, la capa de lógica de negocios y la capa de acceso de datos.

Cuando mi DAL encuentra una excepción, debería coger allí o dejar de nuevo la burbuja hasta la capa de servicio? Y por qué?

Por favor, ignore cualquier participación del cliente para este escenario, soy sólo se ocupa de registrar las excepciones en el SVC WCF.

¿Fue útil?

Solución

También depende de cómo esté la arquitectura de su solución. Por ejemplo, si las capas DAL y BLL están destinados a ser componentes totalmente independientes, entonces no pueden hacer suposiciones acerca de quién los está llamando. Como tales, deben ambas excepciones de agarre en los límites del componente, ingrese esas excepciones, a continuación, permitir que la excepción se propague. Es posible que quieran envolver la excepción general en una capa de excepción específica:

catch (Exception ex)
{
    Logger.Log(ex);
    throw new DalException("Unhandled exception in DAL", ex);
}

Si sabe éstos sólo serán utilizados como parte de su aplicación general, entonces se puede diferir el registro a la capa más externa - la capa que, si no captura la excepción, la excepción no se registrará.

Otros consejos

Hay un plazo para que - Excepción de blindaje. Básicamente se debe evitar excepciones sistema para viajar a nivel superior, ya que esto podría dar una atacker una vista de la arquitectura del sistema. WCF excepción de blindaje puede capturar las excepciones de cierto tipo y reemplazarlos con excepciones de otro tipo. Por ejemplo, podría coger Stackoverflow excepción y reemplazarlo con su SystemException personalizado. Si utiliza Enterprise Library que podrían configurar también para registrar estas excepciones cuando se sustituyen

Utilizando el manejo de excepciones bloque de Enterprise Library 3.0

supongo que depende de cómo se consume el servicio y que (si alguno) que desea consciente cuando se produce una excepción.

Por ejemplo, si está desarrollando una aplicación de gestión interna de misión crítica, es posible que desee los detalles de la excepción a la burbuja a través de la capa de servicio a la interfaz de usuario que consume la aplicación por lo que terminan el usuario puede ponerse en contacto con una desarrollador para obtener rápidamente el problema resuelto.

Sin embargo, digamos que su servicio es consumido por una página web pública. Es probable que todavía desea que la capa de servicio para detectar el error de alguna manera, pero es posible elegir pasar un mínimo de información al cliente final, proporcionar un mensaje de error genérico para el usuario final, y escribir los detalles de la excepción de un registro de errores de desarrolladores para su revisión.

Al final, sigo pensando que desea que la excepción a la burbuja hasta la capa de servicio, pero la forma de manejar la excepción y decidir lo que la información pase al cliente final depende de usted.

Por lo general utilizan un controlador de errores genéricos (aplicación System.ServiceModel.Dispatcher.IErrorHandler) que está conectado a los servicios web por un ServiceBehavior en el archivo de configuración.

Los intercepta método IErrorHandler.ProvideFault excepciones lanzadas desde el servicio y:

  • Registros ellos;

  • Pasa FaultExceptions a través de como está;

  • Convierte los "negocios" excepciones (por ejemplo violaciones de las reglas de negocio) arrojados por el BLL a FaultExceptions con un código de error "emisor / cliente";

  • Convierte excepciones técnicas (por ejemplo, tirados por el DAL) a FaultExceptions con un código de fallo "receptor / servidor".

De este modo, el código de servicio en sí sólo contiene el código de negocio y no necesita capturar las excepciones.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top