Introducción
Siguiendo con esta secuencia de POST orientados a tratar de explicar cómo funciona el motor de Reglas de Windows Workflow Foundation. En el primer POST tenemos se explica cómo funcionan la evaluación de reglas de un RulesSet y cómo se re evalúan por defecto.
En este pequeño POST trataré de explicar cómo se puede controlar la ejecución de reglas atómicas del RuleSet sin dependencia entre ellas. La idea es que en algunos escenarios complejos, quien escribe las reglas necesita tener mayor control sobre el comportamiento de las re evaluaciones, específicamente limitar la cantidad de reevaluaciones. Con esto se busca evitar loops infinitos, resultados erróneos por iteraciones de las reglas y algo no menor, mejorar el desempeño.
Control de dependencias de Reglas (Forward Chaining Control)
En nivel de control que permite Windows Workflow Foundation se puede configurar en dos puntos:
- Conjunto de Reglas (RuleSet): con la propiedad Chaining Behavior.
- En cada Regla (Rule): con la propiedad Reevaluation Behaivor.
Chaining Behavior
Esta propiedad actua a nivel de RuleSet, y tiene las siguientes tres posibilidades:
1. Full Chaining: este es el comportamiento por defecto que está descrito en el primero post de esta serie. Pueden verlo aquí.
2. Explicit Update Only: está opción deshabilita las dependencias implícitas y por atributos, dejando la posibilidad solo a las explicitas declaradas usando Update.
Un ejemplo sería con el RuleSet del código 1 y los métodos del código 2 utilizando Chaining Behavior con el valor por defecto Full Chaining el valor de salida de las variables A, B, C, D y E son 15, 5, 5, 2 y 7 respectivamente.
Ahora si se cambia la propiedad Chaining Behavior a Explicit Update Only, el resultado cambia a 15, 0, 5, 2, 0. Esto ocurre porque en este modo de se ignoran las dependencias declaradas como atributos.
|
Código 1
|
private int A = 0; private int B = 0; private int C = 5; private int D = 2; private int E = 0; //Omitido el resto del código….Ver el proyecto de ejemplo [RuleWrite("B")] private void CambiarB(int valor) { this.B = valor; } [RuleWrite("A")] private void CambiarA(int valor) { this.A = valor; } [RuleWrite("E")] private void CambiarE(int valor) { this.E = valor; } |
Código 2
Para poder obtener el mismo comportamiento que en la primera prueba tenemos que cambiar el RueSet a lo mostrado en el código 3.
|
Código 3
Al poner la dependencia de forma explícita entonces el motor de reglas cuando evalúa la regla 2, re evalúa a regla 4. El resultado obtenido es 15, 5, 5, 2 y 7 respectivamente.
3. Sequiencial: esta es la opción final y lo que hace es forzar a que el motor realice las evaluaciones en un orden línea estricto, es decir no re evalúa las dependencias.
Si al ejemplo anterior, le cambiamos el valor a Secuencial, entonces obtenemos el resultado 15, 0 ,5, 2 y 0 porque no hay re evaluación de la Regla 4
Reevaluation Behavior Property
Está propiedad se aplica a nivel de Reglas y permite la re evaluación o no de la regla. Los valore posibles son:
-
· Always: es el comportamiento descrito hasta ahora y el que viene por defecto.
-
· Never: al marcar una regla con Never está ejecutará las acciones THEN o ELSE sólo una vez según corresponda.
En el ejemplo anterior, si la Regla 4 es marcada con Never entonces los valores de salida con 15, 0, 5, 2 y 0 porque la Regla 4 no se re evaluó.
Función Halt
Está función es muy interesante porque permite controlar la ejecución de dependencias entre reglas relacionadas. Al incluir Halt en la acción THEN o ELSE, entonces el RuleSet retorna de manera inmediata el control al código que lo invocó.
Con lo expuesto en este POST más el primer POST de RULE ENGINE ya se puede echar a volar la imaginación y buscar las aplicaciones prácticas de está tecnología. Yo ya la uso en proyectos Reales.
Espero seguir con otro Post (esto solo es una expresión de deseo) que muestra otros aspectos de Rules Engine de Windows Workflow Foundation.
EL código fuente del ejemplo mostrado se puede descargar desde aquí.
Salu2
..:: Liarjo of Locksley ::.. 