En el anterior post se introdujo un poco acerca del motor de reglas y como se podía hacer uso de los plugin para incorporar este motor de reglas dentro de nuestras aplicaciones, sin duda algo bastante ‘cool’ como diría el amigo David Salgado. En esta ocasión me gustaría mostrar como se manejan las dependencias entre las reglas y los mecanismos que nos proporciona Windows Workflow Foundation para manejar estas dependencias.
Dentro de un mismo RuleSet, o conjunto de reglas, podemos tener dependencias de tal forma que la evaluación de una determinada regla dependa de la evalución de una regla con anterioridad. Por ejemplo, imagínese que tiene un nuevo RuleSet con las siguientes reglas:
Regla 1
IF this.edad > 18 THEN this.MayorDeEdad = true
Regla 2
IF this.MayorDeEdad = false THEN this.CarnetConducir = false
En este caso es evidente que la evaluación de la regla 2 depende de la regla 1 puesto que en esta regla se establece un valor para ‘MayorDeEdad’ lo cual podría provocar que el campo ‘CarnetConducir’ se evaluara de forma incorrecta. En Workflow Foundation las dependencias entre reglas pueden identificarse o declararse de entre algunas de las siguientes formas:
- Implícita
- Basada en atributos
- Explícita
A continuación pasaremos a explicar y analizar cada una de las tres formas:
Implícita
De forma implícita delega al motor de reglas de Workflow Foundation la evaluación de las dependencias. Cuando un conjunto de reglas es ejecutado cada regla determina que campos son leídos en la condición y que campos son establecidos en la acción, de esta forma sabría que la Regla 2 de nuestro ejemplo debería de ser evaluada siempre que la regla 1 ejecutara la acción ‘Then’. Realmente delegando las dependencias de las reglas al motor de reglas de Workflow Foundation resolveríamos la mayoría de nuestros problemas, no obstante para reglas más complejas o bien cuando deseamos ser nosotros quienes manejemos las dependencias deberemos de recurrir a los siguientes modelos de resolución de dependencias.
Basada en Atributos
Cuando una de nuestras reglas llama a algún método, el motor de reglas de WF no puede, como en el caso anterior, determinar que campos son leídos o establecidos. Para resolver estos problemas WF nos proporciona tres atributos con los que podemos decorar nuestros métodos con el fin de informas que campos se leen o establecen, estos atributos son:
- RuleRead
- RuleWrite
- RuleInvoke
Para verlo modificaremos las reglas de nuestro ResultSet que quedarán de la siguiente forma:
Regla 1
IF this.edad > 18 THEN SetMayorDeEdad(true)
Regla 2
IF this.MayorDeEdad = false THEN SetCarnetConducir(false)
En esta situación, tal y como hemos dicho, el motor de reglas no puede determinar de forma implícita que campos se leen y/o escriben para calcular cuando debe reevaluar una regla. Para resolverlo decoraremos el método SetMayorDeEdad con el atributo RuleWrite y RuleRead puesto que en este método se establece un valor de campo.
Código
[RuleWrite(«MayorDeEdad»)]
private void SetMayorDeEdad(bool valor)
{
this.MayorDeEdad = valor;
}
RuleRead nos permite especificar que en un determinado método se lee algún valor a usar en otras reglas del ResultSet y RuleInvoke nos permite decir que dentro de un método se hace una llamada a algún otro método que lee o establece el valor de algún campo implicado dentro de una regla de nuestro ResultSet.
Explícita
Para terminar tenemos un último mecanismo para especificar las dependencias dentro de las reglas, en este caso es un mecanismo explícito ya que somos nosotros mismo quienes dentro de la declaración de la regla decimos que valores estamos leyendo o modificando con el fin de provocar las reevaluaciones de las mismas si es necesario. Para realizarlo utilizaremos la sentencia Update indicándole la ruta del campo tal y como podemos ver en el siguiente Ejemplo:
Regla 1
IF this.edad > 18 THEN this.MayorDeEdad = true;Update(«this/MayorDeEdad/»)
Todo lo que hemos visto hasta ahora está relacionado con la propiedad ‘Chaining’ que podemos establecer en el editor de nuestros RuleSet, esta propiedad puede tomar tres valores:
- Full Chaining
- Explicit Chaining
- Sequential
Full Chaining es la opción por defecto y describe el comportamiento visto hasta ahora, la opción de Explicit Chaining no realiza la validación Implícita ni basada en atributos, solamente toma en cuenta las sentencias Update. Realmente esta opción tiene sentido cuando la reevaluación de las reglas podría resultar costosa o entrar en un proceso cíclico. Para terminar la opción ‘Sequential’ únicamente establece la evaluación de las reglas dado el orden que tengan.
Esto no es todo lo que dan de si las reglas dentro de Workflow Foundation, pero como otra aproximación estoy seguro que es suficiente. Para los que deseen profundizar más, pueden seguir invesetigando acerca de la sentencia Halt, la ejecución de reglas basadas en prioridades y el procesamiento de las colecciones de reglas.
Espero que os haya gustado.. un saludo
Unai Zorrilla Castro
