Prácticas recomendadas de manejo de excepciones de base de datos

Question

¿Cómo maneja las excepciones de base de datos en su aplicación?
¿Está tratando de validar datos antes de pasarlos a DB o simplemente confiar en la lógica de validación del esquema DB?
¿Intenta recuperarse de algún tipo de error de DB (por ejemplo, tiempos de espera)?

He aquí algunos enfoques:

1. Validar los datos anteriores pasándolo a DB
2. validación de izquierda a DB y manejar excepciones DB adecuadamente
3. Validar en ambos lados
4. Validar algunas limitaciones obvias en los negocios lógica y validación compleja izquierda a DB

¿Qué enfoque utiliza? ¿Por qué?

actualizaciones:

Me alegro de ver cada vez mayor discusión.
Tratemos de resumir las respuestas de la comunidad.

Sugerencias:

• Validar en ambos lados
• Restricciones de comprobación lógica de negocio en lado del cliente, permiten DB hacen comprobaciones de integridad from hamishmcn
• Comprobar temprano para evitar molestar a DB from ajmastrean
• Comprobar pronto para mejorar la experiencia del usuario from Will
• Mantener el código de interacción de BD en su lugar al simplificar el desarrollo from hamishmcn
• mapeo objeto-relacional (NHibernate, LINQ, etc) puede ayudar a hacer frente a restricciones from ajmastrean
• validación del lado del cliente es necesaria por razones de seguridad from Seb Nilsson

¿Tiene todo lo demás ¿decir? Esto se convierte a la pregunta específica de Validación. Nos falta el núcleo, es decir, "Mejores prácticas de error relacionadas con la base de datos", ¿cuáles manejar y cuáles Bubble up?

Answer 1

En general, intento validar los datos tan pronto como sea posible después de haberlos ingresado. Esto es para poder dar mensajes útiles al usuario antes de que hayan hecho clic en "enviar" o su equivalente.
En el momento en que se trata de realizar la llamada de DB, tengo la esperanza de que los datos que estoy transmitiendo sean bastante buenos.
Intento mantener las llamadas a bases de dato en el único archivo (o grupo de archivos) que comparten métodos de ayuda para que el programador (yo o quien sea que agregue llamadas) lo más fácil posible para escribir en un registro detalles sobre la excepción y qué parámetros se pasaron en etc.

Answer 2

Intento validar en ambos lados. La regla 1 que siempre sigo nunca es la entrada de confianza del usuario. Después de esto hasta su conclusión, usualmente tendré alguna validación del front end en el formulario/página web que ni siquiera permitirá la presentación con datos formados incorrectamente.Esta es una herramienta contundente, lo que significa que puede verificar/analizar el valor para asegurarse de que un campo de fecha contiene una fecha. A partir de ahí, generalmente dejo que mi lógica empresarial compruebe si la entrada de datos tiene sentido en el contexto de cómo se envió. Por ejemplo, ¿la fecha presentada cae dentro del rango esperado? ¿El valor de la moneda presentada cae dentro del rango esperado? Finalmente, en el lado del servidor, las restricciones y los índices de clave externa pueden detectar cualquier error que se deslice, lo que generará una excepción de base de datos como último recurso, que puede ser manejado por el código de la aplicación. Utilizo este método porque filtra tantos errores como sea posible antes de invocar la llamada al DB.

Answer 3

Desea reducir los viajes innecesarios a la base de datos, por lo que realizar una validación dentro de la aplicación es una buena práctica. Además, le permite manejar los errores de datos donde es más fácil recuperarlos: cerca de la interfaz de usuario (ya sea en el controlador o en la capa de IU para aplicaciones más simples) donde se ingresan los datos.

Sin embargo, hay algunos errores de datos que no puede verificar programáticamente. Por ejemplo, no puede validar datos sobre la existencia de datos relacionados sin realizar una ida y vuelta a la base de datos. Los errores de datos como estos deben ser validados por la base de datos a través del uso de relaciones, desencadenadores, etc.

Donde lidiar con los errores devueltos por las llamadas a la base de datos es interesante. Podría tratar con ellos en la capa de datos, la capa de lógica de negocios o la capa de interfaz de usuario. La mejor práctica en este caso es permitir que esos errores broten hasta el último momento responsable antes de manejarlos.

Por ejemplo, si tiene una aplicación web ASP.NET MVC, tiene tres capas (de abajo hacia arriba): Base de datos, controlador y UI (modelo, controlador y vista). Cualquier error arrojado por su capa de datos debe permitirse que suba a su controlador. En este nivel, su aplicación "sabe" lo que el usuario está intentando hacer, y puede informar correctamente al usuario sobre el error, sugiriendo diferentes formas de manejarlo. Intentar recuperarse de estos errores dentro de la capa de datos hace que sea mucho más difícil saber qué está sucediendo dentro del controlador. Y, por supuesto, colocar la lógica comercial dentro de la UI no se considera una mejor práctica.

TL; DR: validar en todas partes, manejar los errores de validación en el último momento responsable.

Answer 4

El tipo de aplicaciones que estaba escribiendo (desde entonces he cambiado de trabajo) eran aplicaciones propias de clientes gordos.
Intentaría mantener la lógica comercial en el cliente y realizar más validación mecánica en el DB (es decir, validación que solo se relaciona con la capacidad de ejecución del procedimiento, en contraposición a la validación de nivel superior).
En resumen, valide donde pueda y trate de mantener los tipos relacionados de validación juntos.

Answer 5

@aku: DRY es agradable, pero no siempre es posible. La validación es uno de esos lugares, ya que tendrá tres lugares completamente diferentes y no relacionados donde la validación no solo es posible sino que es absolutamente necesaria: dentro de la IU, dentro de la lógica comercial y dentro de la base de datos.

Piense en una aplicación web. Desea reducir los viajes al servidor, por lo que incluye la validación de JavaScript de la entrada de datos del cliente. Pero no puede confiar en lo que ingresa el usuario, por lo que debe realizar la validación dentro de la lógica de su negocio antes de tocar la base de datos. Y la base de datos debe tener su propia validación para evitar la corrupción de datos.

No hay una manera clara de unificar estos tres tipos diferentes de validación dentro de un solo componente.

Hay algunos intentos se hacen para unificar responsabilidades transversales como validación dentro de los inyectores de política como del grupo P & P Policy Injection Application Block combinado con su Validation Application Block, pero estos se basan todavía código.Si tiene una validación que no está en el código, todavía tiene que mantener la lógica paralela por separado ...

Answer 6

Una herramienta de mapeo relacional de objetos (ORM), como NHibernate (o mejor aún, ActiveRecord), puede ayudarlo a evitar mucho de validación al permitir que el modelo de datos se construya directamente en su código como una clase C# apropiada. También puede evitar viajes a la base de datos, gracias a los excelentes modelos de caché y validación integrados en el marco.

Answer 7

Hay una razón de peso para validar tanto en el lado del cliente como en el de la base de datos, y eso es security. Especialmente cuando comienzas a usar material AJAX, URL pirateables y otras cosas que hacen que tu sitio (en este caso) sea más amigable para los usuarios y piratas informáticos.

Validar en el cliente para proporcionar una experiencia sin problemas para decirle al usuario que corrija su entrada. También valide en la base de datos, (o en la lógica de negocios, si esto se considera una puerta de enlace totalmente segura a la base de datos) para la seguridad de su base de datos.