Representar las reglas comerciales con excepciones

Question

Sé que es caro pero (en mi opinión) creo que es una muy buena práctica. Estoy hablando de reglas como decir, no puedes guardar una factura si no eres un vendedor ... así que en ese caso lanzar una excepción diciendo 'no estás autorizado' o tal ...

Otro enfoque sería tener objetos con un estado o algo así

¿Hay algún otro enfoque? ¿Cómo te sientes al respecto?

Answer 1

Si te refieres a representar las verificaciones de reglas comerciales individuales con excepciones, entonces no creo que sea una muy buena idea. Muchas veces debe informar más de una condición fallida, y no detenerse en la primera.

Por otro lado, creo que verificar todos reglas y después Lanzar una excepción con el resumen es una buena práctica.

Answer 2

En el ejemplo que nos ha dado, creo que plantear una excepción es una mala idea. Si sabe que el usuario no está autorizado antes de comenzar a trabajar y aún les permite hacer alguna función y luego golpearlos con un mensaje después de haber completado la tarea, ese es solo un mal diseño.

Usar excepciones para hacer cumplir las reglas comerciales no es un buen diseño.

Answer 3

No veo qué valor tiene una excepción para crear una buena lógica de negocios. Hay docenas de enfoques para manejar la lógica de negocios que no implican el uso de un sistema destinado a abordar condiciones inesperadas en la operación de un sistema.

Está esperado que en la lógica comercial, las condiciones no se cumplirán; Esa es la razón para tenerlo en primer lugar, y no desea aprovechar el mismo mecanismo que maneja fallas inesperadas de E/S, errores de memoria y referencias nulas. Esas son fallas del sistema, pero la detección de condiciones comerciales no satisfechas es la operación exitosa del sistema.

Además, es un sistema que está maduro para consecuencias no deseadas. Debido a que una excepción tiene que ser atrapada en algún momento, corre el riesgo de tener una nueva regla de negocio la excepción de la excepción de ser atrapada en algún lugar de que no está previsto o tiene la oportunidad de tener el código que busca reglas comerciales que atrapan excepciones que en realidad no se significan para ello. Sí, estas condiciones se pueden contabilizar con buenas prácticas de codificación, pero en cualquier sistema no trivial en el que más de un desarrollador esté funcionando, ocurrirán errores y solo tiene que esperar que no sean errores costosos.

Answer 4

Expresar las reglas comerciales es una cosa, implementarlas es otra

Piense en la experiencia del usuario; Si el usuario no es un vendedor, ¿por qué darles un botón que diga 'crear factura'? en absoluto?

Answer 5

Eso depende completamente de lo que se está haciendo.

Primero, ¿cuál es el comportamiento real que desea? Si alguien está ingresando su propia información, entonces un rechazo y un cuadro de diálogo que dice, esencialmente, "no puedes hacer eso" probablemente sea correcto. Si esta es una persona de entrada de datos, que trabaja a partir de un montón de formularios, un cuadro de diálogo probablemente también sea bueno, y la persona de entrada de datos puede poner los formularios inválidos en una pila especial. Si está haciendo un procesamiento por lotes, no desea detener las cosas, pero marcarlo y pasar al siguiente.

Una vez que tenga el comportamiento, debe decidir cómo lo va a implementar. Tener un verificador de reglas de negocios que lanza una excepción es probablemente una buena idea. Devolver un código de regreso y que lo pase es algo más que puede salir mal, y ciertamente no desea que las entradas erróneas sean más allá.

No se preocupe por el gasto de rendimiento. En el caso de un individuo que ingresa datos, es trivial en comparación con los otros tiempos involucrados. Por lo general, el humano llevará la mayor parte del tiempo en ese sistema. En el caso de un trabajo por lotes, si las excepciones son un problema de rendimiento, está ingresando demasiados registros malos, y en realidad manejar y volver a ingresar a todos estos serán más problemas que las excepciones.

Answer 6

Tener una API de excepción robusta y bien diseñada que sea consistente es muy apropiado. El uso de esto para hacer cumplir las reglas comerciales también puede ser apropiado. De hecho, en mi experiencia, cuanto más complicada sea la regla comercial, más probabilidades de que termine siendo manejado de esta manera. A menudo es igual de fácil, si no más fácil, escribir un sistema donde se esperan excepciones que escribir una lógica de ramificación autorizada.

Esto quiere decir que las reglas simples que se pueden describir en una sola oración generalmente deben implementarse de manera preventiva o autorizada dependiendo de cuál sea. Sin embargo, si tiene una regla que es multidimensional y requiere más de tres o cuatro factores (especialmente si la selección de estos factores se basa en uno o más de los otros factores), la codificación de excepción puede ser más mantenible. A menudo, en estos casos, la ruta lógica tendrá muchas excepciones precursoras que deben ser lanzadas (verifica por qué la acción no se puede realizar) luego (o viceversa) hay una caída de seguridad (para verificar que la acción esté autorizada ), a veces habrá una lógica de acumulación autorizada que debe verificarse (disponibilidad descendiente/antepasado, establece que los objetos deben ponerse en, etc.), luego la lógica caerá al proceso real que puede incluir la autoridad más directa autorizada más directa Comprobación lógica directamente pertinente al proceso.

Un beneficio que deriva de este tipo de lanzamiento de excepciones es que le permite separar y reutilizar las excepciones precursoras en múltiples áreas de su proyecto. (Esta es la esencia de la programación orientada a los aspectos). Al hacer esto está encapsulando un aspecto particular de sus reglas comerciales generales en un componente autoconsciente y mantenible. En general, estos componentes corresponderán 1-1 con los mensajes de error lanzados. (Aunque a veces tendrá un componente que arroja varias excepciones diferentes, casi nunca debe tener la misma excepción lanzada de múltiples componentes).

En mi opinión, es más difícil diseñar sistemas que se basan en excepción y el tiempo de desarrollo inicial es más largo, ya que debe desarrollar el proceso de excepción en todos los niveles de N. Sin embargo, este sistema generalmente terminan siendo mucho más estables. Si bien nunca es posible diseñar un sistema que "no falle", el beneficio del diseño basado en excepción es que siempre está anticipando la falla. Para la mayoría de las personas, el proceso puede ser contradictorio. Es como pedir instrucciones y que alguien te diga todas las calles que no debes encender.