.NET Compact Framework 3.5

El equipo de desarrollo de .NET Compact Framework acaba de publicar un post dónde anuncia las novedades que vendrán incorporadas en Orcas en cuanto a la plataforma de desarrollo para dispositivos móviles. Parece que tienen un buen trabajo a realizar ya que entre sus intenciones está la implementación de un subset de las características de LINQ, la incorporación de un subconjunto de WCF que permitirá resolver o atenuar los problemas actuales en cuanto a direccionamiento de los dispositivos móviles. En el mismo post puedes encontrar los enlaces para descargarte una máquina virtual para realizar las pruebas de .NET Compact Framework 3.5

 

Saludos

Unai Zorrilla Castro

WF y WCF trabajando juntos

Se acaba de publicar un ejemplo en MSDN dónde se pone de manifiesto como juntar tecnologías como WF y WCF, este ejemplo es básicamente una refactorización de un ejemplo que se mostró con la llegada de .NET para mostrar cómo realizar aplicaciones distribuidas usando .NET Remoting, ¡esos viejos tiempos!!. En esta refactorización tenéis toda la parte de servicios expuesta con Windows Communication Foundation y la lógica del mismo incluida dentro de un Workflow usando los servicios de intercambio de datos para la comunicación con el servicio.

 

Integrating Windows Communication Foundation y Windows Workflow Foundation

 

 

Espero que os guste

Unai Zorrilla Castro

Liberado Sql Compact Edition

En unos de mis post anteriores expuse las novedades de Sql Compact Edition, no sé porque razón, pero la liberación de la versión no era la final sino una RC… hicieron una especie de marcha atrás, seguramente porque detectaron algún error. Ahora por fin está liberada junto a una serie de herramientas:

Microsoft Sql Server 2005 Compact Edition Server Tools

Microsoft Sql Server 2005 Compact Edition Tools Of VS 2005 SP1

Microsoft Sql Server 2005 Compact Edition Developper SDK

 

Podeis descargarlo todo desde aqui

Saludos

Unai

 

 

El motor de reglas de Workflow Foundation (II)

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