10.20.2011

Aprendiendo WF parte 5: Clases como Parámetros

Continuando con la serie de post acerca de WF, en esta ocasión vamos a trabajar utilizando clases como parámetros. Esto desde el punto de vista arquitectura tiene mucho sentido porque nos va a permitir utilizar nuestras entidades de negocio como parámetros de los workflows que al final terminarán invocando nuestros componentes de negocio.

La clase Persona

Para este ejemplo vamos a utilizar una clase llamada persona, la cual se muestra a continuación:

image

El Workflow

Vamos a crear un nuevo Workflow en donde vamos a definir si una persona puede hacer el examen para tener permiso de conducir – licencia. Para esto vamos a recibir como parámetro una instancia de una persona y vamos a verificar la Edad de la persona, si la persona es mayor de 18 años entonces puede tomar el examen lo cual será indicado retornando en una variable booleana el valor verdadero, en caso contrario vamos a retornar falso.

Para agregar un workflow a la solución actual iniciamos agregando una nueva actividad al proyecto – recordemos que los workflows en sí son actividades que contienen otras actividades.

image

En el workflow recién creado vamos a crear un parámetro de entrada llamado pPersona del tipo Persona. Para tener acceso a este tipo desde el UI de parámetros de workflow, primero tenemos que compilar la aplicación, seguidamente procedemos a definir la variable y a asignarle el tipo vía la opción “Browse for Types”.

image

En la pantalla de selección de tipos buscamos la recién definida clase Persona.

image

Ahora procedemos con la definición del parámetro de retorno. En este caso haremos una variable llamada pRespuesta de tipo boolean.

image

Ahora procedemos a crear el workflow. Este decidirá en base a la edad de la persona si esta puede o no hacer el examen de manejo. El workflow se puede ver a continuación.

image

Como se ve en la ilustración anterior, usamos una figura “if” para determinar la edad de la persona y si esta es mayor de 17 años, entonces le asignamos con una figura “Assign” verdadero al resultado, en caso contrario le asignamos falso.

Invocando el workflow

Para invocar el workflow, debemos de crear una instancia de la clase Persona y enviarla vía el diccionario de parámetros al workflow. Además, debemos de recibir la respuesta vía el diccionario de respuesta del workflow.

image

Al ejecutarlo el resultado es el siguiente:

image

Etiquetas de Technorati:

10.15.2011

Aprendiendo WF parte 4: Parámetros de Salida

Continuando con el post anterior, ahora vamos a proceder a trabajar con los parámetros de retorno desde un workflow hecho en WF 4.

En el ejemplo anterior vimos como recibir parámetros desde el programa de consola, luego con el parámetro recibido procedimos a imprimir un mensaje en el workflow – un saludo. Sin embargo, desde la perspectiva de arquitectura de software, el uso de esta primitiva –WriteLine –rompe con una regla fundamental a la hora de trabajar con la separación de responsabilidades de cada capa, ya que hace que workflow que acabamos de crear dependa de la capa gráfica en donde vamos a publicar los mensajes; es decir, solamente vamos a poder utilizar este workflow en una aplicación de consola.

Los Workflows son Ajenos al UI

Pero el problema anterior no se debió haber presentado porque en realidad en una arquitectura de software, un workflow debe de ser independiente de la capa de presentación. Por esta razón vamos a modificar el workflow anterior para que construya el mensaje y lo retorne a la capa de presentación que lo este utilizando. Vamos a agregar una variable de salida al workflow para poder devolver el mensaje tal y como se ve en la siguiente figura:

image

En la variable pSaludo vamos a devolver el mensaje construido. Ahora vamos a modificar el workflow para que construya este mensaje de saludo, para esto debemos deshacernos de la figura de WriteLine y procedemos a utilizar una figura de asignación. El workflow se ve así:

image

Listo, ahora procedemos a recibir el saludo en la aplicación de consola – aunque podría ser desde cualquier otro tipo de aplicación como Web o WPF. Para esto creamos un diccionario similar a de los parámetros en donde vamos a recibir nuestras respuestas. Luego obtenemos el valor de la variable desde este diccionario e imprimimos el valor de la respuesta.

image

El resultado al ejecutar la aplicación anterior es el siguiente:

image

Etiquetas de Technorati:

10.13.2011

Aprendiendo WF parte 3: Parámetros de entrada

Un workflow normalmente se activa a través de un servicio o un componente de negocios. Este workflow por lo general recibe parámetros para poder llevar a cabo el proceso que se desea activar. En este workflow vamos a ver como enviarle parámetros a un workflow en WF.

Crear el Workflow

En primera instancia vamos a crear un workflow muy simple que recibe el nombre de una persona e imprime un saludo con este nombre. Lo primero que tenemos que hacer es crear el parámetro que recibe el workflow; para esto, vamos a crear un argumento de tipo string cuya dirección es “In”.

image

El siguiente paso es agregar una secuencia y una figura de “WriteLine” al workflow y configurarle el texto de la siguiente forma:

image

El workflow debería lucir como se ve a continuación:

image

Paso del Parámetro

Inicialmente, los parámetros se exponen vía propiedades dinámicas a través del workflow y esto permite que de una forma sencilla podamos invocarlo. El código para llevar a cabo esto desde una consola es el siguiente:

image

Si ejecutamos esta consola el resultado será el siguiente:

image

Aunque esta es una forma sencilla de pasar los parámetros, no es la más común a la hora de utilizar WF. Normalmente los parámetros se pasan vía un diccionario de datos a través del constructor de la instancia del tipo tal y como se puede ver en la siguiente figura. Nótese que la llave del elemento tiene que coincidir con el nombre del argumento que está esperando el workflow.

image

Etiquetas de Technorati:

10.09.2011

Creando un proyecto C# con el MSBuild

En la labor de crear un migrador de Oracle Forms a .NET me encontré con una tarea muy interesante: crear un proyecto en C# de forma dinámica, y compilarlo. En este post voy a compartir de forma simple como crear una pequeña aplicación de consola con un editor de texto, como crear un archivo de proyecto y como compilarlo.

La clase Hola en C#

La primera tarea que haremos es crear una clase que despliega un mensaje en la consola. Esta clase esta escrita usando Notepad2 y se presenta a continuación:

image

por supuesto que si quisiéramos podríamos compilar esta clase utilizando el compilador de C# – csc.exe – pero queremos crear dinámicamente el proyecto para agregar todas las clases y archivos necesarios al mismo y poder utilizarlo en Visual Studio.

El MSBuild

Aquí es donde entra el MSBuild. El MSBuild es una plataforma para construir – compilar – aplicaciones. Este contiene un esquema XML para el archivo de proyecto que controla como la plataforma de construcción procesa y construye el software.

Para nuestro proyecto vamos a utilizar el siguiente archivo de proyecto, el cual vamos a llamar proyecto.csproj:

image

Ítems

Los ítems son las entradas para el sistema de construicción, y normalmente se representan a través de archivos. Estos ítems se agrupan en grupos del mismo tipo. En el archivo de proyecto anterior creamos un ItemGroup con archivos de tipo Compile – hola.cs – dentro del mismo.

Targets

Agrupan tareas en un orden particular para que sean ejecutadas por el motor del MSBuild; en nuestro caso, creamos un Target que invoca el compilador de C# – csc.exe – para compilar cada uno de los archivos cs en el item group.

Compilación del Proyecto

Para compilar nuestro proyecto solamente tenemos que ir al command prompt de Visual Studio y digitar el siguiente comando:

image

Si el comando se ejecuta de manera exitosa entonces podremos ver el resultado en nuestro command prompt.

image

si vemos el contenido del directorio nos daremos cuenta que se ha creado un archivo con extensión exe. Si ejecutamos “hola” en el prompt veremos que nuestra aplicación se ejecuta de la forma correcta.

image

Etiquetas de Technorati:

10.04.2011

Como ver los comandos enviados al Entity Framework

Cuando utilizamos el Entity Framework constantemente nos preguntamos ¿ y que fue lo que se envió a la base de datos? A partir de esta pregunta surgen muchas herramientas tales como "profilers" comerciales - como eProf - , y el analizador de consultas de SQL Server o el de la base de datos que estemos utilizando. Sin embargo, estas soluciones pueden no ser suficientes porque pueden existir escenarios en donde sea necesario por seguridad o auditoría almacenar las sentencias SQL que se envían a la base de datos. Este post da solución a este problema.

Existe un tipo en el EntityFramework conocido como el ObjectSet<T>. Esta clase representa un conjunto de entidades sobre la cual se pueden ejecutar operaciones de eliminación, actualización, consulta, etc. El ObjectSet además tiene un método que se llama ToTraceString() el cuál nos permite obtener el comando enviado a la base de datos.

Para esto vamos a hacer un ejemplo sencillo donde vamos a consultar la tabla de consultores que vemos en el siguiente modelo del EF.

image

Si queremos obtener los consultores en la base de datos y a la vez ver la consulta enviada por parte del EF procedemos a ingresar el siguiente código.

image

El resultado a la hora de ejecutar la consulta anterior es el siguiente:

image

Etiquetas de Technorati:

10.02.2011

Aprendiendo WF parte 2

Continuando con esta serie de post acerca de Workflow Foundation, esta semana vamos a conversar acerca del manejo del hosting cuando utilizamos esta tecnología. Como recordarán en el post anterior, en ambos casos creamos una instancia del workflow utilizando una aplicación de consola, tal y como se puede apreciar en la siguiente imagen.

image

Al ser WF4 parte del framework de .NET se permite “hostear” y ejecutar un workflow en cualquier tipo de aplicación que este ejecutando el Framework de .NET – en este caso el 4.0. Podemos hostear un workflow como un servicio en WCF, en una aplicación ASP.NET, en una aplicación de consola, etc. Algo que siempre debemos considerar es que los workflows deben de ser independientes de el ambiente que los hostea, esto con el fin de permitir que estos puedan ser ejecutados e invocados desde cualquier tipo de consumidor.

El método Invoke de la clase WorfklowInvoker lo que haces es crear un workflow de manera sincrónica y retorna un diccionario de valores los cuáles representan los valores de retorno del workflow. Es importante destacar que la ejecución del workflow esta garantizada en el thread que lo invoca.

Si vemos la definición del método en el msdn, podemos ver que existen muchas versiones sobre cargadas del método; sin embargo, nosotros estamos utilizando la versión que recibe una actividad:

image

Y entonces surge la pregunta ¿No estamos enviando un workflow como parámetro? ¿ Porqué estamos utilizando una función que recibe una actividad? En realidad este es un concepto muy importante y es algo que tenemos que tener muy presente cuando utilizamos WF4. En WF4 los workflows son actividades que contienen otras actividades y por lo tanto cuando inicio un workflow utilizo la función que recibe una clase de tipo Activity, y dado que los workflows heredan de la clase Activity y gracias al polimorfismo, podemos enviar nuestro workflow como parámetro para este método.

Si vemos el código XAML del workflow que creamos en el ejemplo anterior – los workflows en WF4 son XAML – veremos que el nombre del workflow esta definido a través de la palabra reservada x:Class y para este caso el nombre del tipo es Workflow1 – para ver un workflow en xaml le damos botón derecho sobre el archivo y seleccionamos la opción ViewCode.

image

Etiquetas de Technorati: