Error al manejar en la arquitectura de 3 capas

Question

¿Cómo implemento el manejo de errores de manera elegante? Por ejemplo, mi capa de acceso a datos puede arrojar 2 tipos de errores: 1) acceso no autorizado, en cuyo caso la página debe ocultar todo y mostrar el mensaje de error 2) errores que informan al usuario que algo como esto ya existe en la base de datos (digamos que el nombre no es único, por ejemplo), y en este caso no quisiera ocultar todo.

Editado:

Como resultado de algunos comentarios aquí ideé que debería crear derivados de tipos de excepción especializados, como NotAuthorizedException, DuplicateException, etc, etc .... es todo lo fino y elegante, sin embargo puedo ver 2 problemas potencialmente:

1) Cada proceso almacenado tiene un campo de retorno p_error donde contiene un mensaje de error. Al obtener los datos de DB, necesito verificar este campo para ver qué tipo de error se ha devuelto, para poder lanzar las excepciones apropiadas. Por lo tanto, todavía tengo que almacenar mis tipos de error/mensajes de error en alguna parte ... En otras palabras, ¿cómo debo enviar el mensaje exacto al usuario (en ciertos momentos) sin verificar primero el campo p_error? Lo que me devuelve al objeto de error. ¿Nadie?

2) Esto puede convertirse potencialmente en una pesadilla donde el número de excepciones es igual a la cantidad de tipos de mensajes de error.

¿Falta algo aquí?

Muchas gracias a todos!

Answer 1

Crea tu propia capa de excepción.

DALExceptionManager DuplicateException DatabaseException

BLLExceptionManager NotAuthorizedException InvalidDateException

en su capa de presentación, añadir este referencias y crear un gestor de excepciones común. De esta forma, sabrá cómo tratar los mensajes de excepción.

Answer 2

Debe consultar el bloque de manejo de excepciones en Enterprise Library. Muchos buenos consejos y codeware rodean las excepciones y las pasan entre capas.

Answer 3

¿Cuál es la capa de su empresa y por qué no está revisando la autorización y la integridad? El DAL es de un nivel demasiado bajo para verificar esas reglas: si se produce un problema allí, es prácticamente el momento de lanzar una excepción. La capa empresarial o los controladores pueden detectar esa excepción y mostrar un mensaje razonable, pero no es algo que deba hacer regularmente.

Answer 4

Una opción que estaba pensando en usando es crear una clase de error, pero entonces yo tendría que pasarla de la interfaz de usuario a la capa de negocio y la continuación de los datos capa de acceso por referencia

No estoy seguro de entender esto. No tiene que pasar el objeto de error en cada capa. Por ejemplo, en uno de sus ejemplos, errors that inform the user that something like this already exists in the database (say name not unique - for example), el marco podría generar una excepción sql, y solo necesita detectar la excepción específica en su capa empresarial o capa UI.

El bloque de manejo de excepciones de la biblioteca Enterprise sugerido por otras personas le permitirá definir un manejo de excepciones basado en políticas en su archivo web.config. Podría ser un buen lugar si desea desarrollar alguna aplicación empresarial. Pero para una aplicación simple, es posible que no necesite ir tan lejos.

Answer 5

Lo que sucede en las capas superiores no depende de su Capa de acceso a datos. Ni siquiera debería estar al tanto de lo que las capas superiores van a hacer. Si tiene un error duplicado de clave, entonces debería arrojar algo así como una "DuplicateKeyException". Si tocas un error de autorización (supongo que te refieres a "excepción"), entonces no hagas nada con él, déjalo volver a la capa de interfaz de usuario, que puede mostrar una página de error apropiada.

Recuerde que los valores de estado de error y esas cosas son la razón por la que inventamos las excepciones.

Answer 6

El bloque de manejo de excepción de la biblioteca de empresa es la bomba que muchos han señalado. Al usar políticas, puede hacer cosas como registrar la excepción, envolverla en una excepción diferente, lanzando una nueva excepción en lugar de la original. Además, si está buscando realizar acciones específicas basadas en errores de autenticación o errores de registro duplicados, etc., siempre puede crear clases de excepciones derivadas específicas y detectar esos tipos de excepciones que excluirían la necesidad de pasar cualquier objeto de arriba hacia abajo. Las excepciones siempre deben subir, no bajar.