Babeos: hacer cosas complejas dentro de una condición o consecuencia de la regla

Question

En mi empresa, planeamos usar BRools A BRE para un par de proyectos. Ahora intentamos definir algunas mejores prácticas.

Mi pregunta es qué debería ser y no debe hacerse dentro de una condición/consecuencia de la regla. Dado que podemos escribir Java directamente o llamar a los métodos (por ejemplo, desde un objeto global en la memoria de trabajo).

Ejemplo. Dada una regla que evalúa un objeto genérico (por ejemplo, una persona) tiene una propiedad establecida en True. Ahora, esa propiedad específica solo se puede definir para que ese objeto vaya a la base de datos y obtenga esa información. Entonces tenemos dos formas de implementar eso:

Alternativa A:

• Vaya a la base de datos y obtenga la propiedad del objeto (verdadero/falso, un código)
• Inserte el objeto en la memoria de trabajo
• Evaluar la regla

Alternativa B:

• Inserte un objeto global que tenga un método que se conecta a la base de datos y verifique la propiedad del objeto dado.
• Inserte el objeto a Eval en la memoria de trabajo
• En la regla, llame al objeto global y realice el acceso a la base de datos

¿Cuál de ellos se considera mejor? Realmente me gusta A, pero a veces B es más sencillo, sin embargo, ¿qué pasaría si se plantea algo así como una excepción de la base de datos?

He visto la alternativa B implementada en el libro DRools 5.0 de Packt Publishing, sin embargo, se están burlando y no hablan sobre las implicaciones reales de ir a la base de datos.

Gracias,

Answer 1

También tengo la necesidad de obtener datos externos de otro sistema (base de datos, llamadas de servicio, etc.), así que he tratado un poco con esto. Personalmente, tomaría esa decisión basada en si sabrá qué hechos necesitará por adelantado. Si es así, entonces, no dude en hacer sus llamadas en Java. Esto le permitirá hacer un mejor manejo de errores. Y si no poder recuperar ciertos datos significa que ejecutar el motor de reglas es un no-go, evitará el trabajo de crear la sesión, insertar hechos, establecer globales, etc. No tiene sentido comenzar si solo vas a detener ().

Pero, por supuesto, también hay casos en los que no poder recuperar datos no debería evitar que se ejecute. En algunos de esos casos, la alternativa A y B funcionarían igualmente bien. Pero suponga que la necesidad de ciertos datos depende de otras cosas. Por ejemplo, trabajo en una aplicación que evaluó lo que son esencialmente grandes árboles lógicos y los Leafs se evalúan utilizando datos de llamadas de servicio. Si dos hojas estuvieran juntas, por lo que ambos tuvieron que ser ciertos para que su rama fuera verdadera, tan pronto como una de ellas evaluó a falsas, esa rama se vuelve falsa y ya no necesito evaluar la otra hoja. Eso significa que habría sido un desperdicio haber precargado los datos que habría necesitado para evaluarlos. Recuperar datos "bajo demanda" es una razón por la cual los motores de reglas como Jess también admiten encadenamiento hacia atrás Además del encadenamiento a avance predeterminado.

Hasta que encadenado hacia atrás Esta completo En la baba, la alternativa que he visto sugerí es usar el "De" Palabra clave. He tenido suerte con eso, pero hay dos cosas a considerar:

1. Los babeos consultan la declaración "de" repetidamente mientras el motor de reglas funciona. Utilizo almacenamiento en caché en mi capa de servicio, por lo que esto es tan dañino como una búsqueda de hashmap, pero si no almacena en caché, corre el riesgo de hacer sin saberlo docenas, cientos o miles de llamadas de servicio.
2. Si no encuentra los datos que esperaba, no hay un lugar para manejar errores. Esto es lo que aludió Steven Herod. El motor de reglas continuará y seguirá evaluando la expresión que le dio. En situaciones en las que necesitaba tomar algunas medidas como llamar a Halt (), hice la llamada de servicio en la consecuencia de la regla.

Espero que esto ayude. Avíseme si hay algo que pueda aclarar o ampliar.

Answer 2

Una de las cosas sobre las reglas es que pueden ser ejecutados muchas, muchas veces. Particularmente si comete un error con las condiciones de su regla. Eso obviamente tiene un impacto de rendimiento.

Luego me inclino a preferir la opción A, preparar sus hechos afuera e inserte en la memoria de trabajo para su evaluación.

Ciertamente, también existe la opción de dividir las reglas en las reglas de carga de datos y luego la evaluación de reglas comerciales (utilizando el flujo de reglas, por ejemplo).

Eso le daría un control declarativo de poblar sus datos fuera del código.