Continuando con el artículo de introducción a CAB, en este post voy a explicar los conceptos básicos de Smart Client Software Factory (SCSF), el proyecto que nos permite automatizar el desarrollo de aplicaciones compuestas usando CAB.

Si ya estuvieron haciendo pruebas con CAB se habrán dado cuenta de que se requiere mucho trabajo extra para crear los nuevos elementos como ser, Workitems, Presenters, Controllers, publicaciones y subscripciones a eventos y comandos, etc.. SCSF nos ofrece un conjunto de asistentes (recipes) y guías que nos ayudan a crear estos elementos en forma automatizada y empleando un diseño adecuado.

Básicamente, SCSF es un agregado para el Visual Studio que añade nuevos tipos de proyectos y asistentes para la creación automatizada de los elementos nombrados. SCSF también posee proyectos de ejemplos (Hands on Labs y Quickstarts) y documentación que nos guían en el aprendizaje e implementación de aplicaciones SCSF.

Si en este artículo encuentra alguna palabra que desconoce es probable que encuentre su definición en el Glosario de CAB en mi post anterior de Introducción a Composite UI Application Block.

¿Qué nos ofrece SCSF?

Con SCSF se obtienen todos los beneficios del desarrollo de aplicaciones con CAB, y además:

• Automatización de varias tareas del desarrollo de una aplicación CAB/SCSF.
• Guías para las tareas que no pueden ser automatizadas.
• Nuevos elementos que añaden y extienden las funcionalidades originales de CAB (ej. Entity Translator, Disconnected Service Agent, Action Catalog).
• Ejemplos, documentación y muchos recursos para el aprendizaje.
• Excelente soporte en el foro del proyecto en CodePlex.

Nuevos elementos

Los proyectos que sean creados usando SCSF poseen en la misma solución un conjunto de clases que añaden nuevas funciones o que encapsulan los elementos originales de CAB. Los nuevos elementos y conceptos que se deben de tener en cuenta en SCSF son:

Nota: Es importante tener en cuenta que la siguiente lista es sólo de algunos de los conceptos más importantes introducidos por SCSF y por lo tanto deja de lado muchos conceptos de CAB que son de vital importancia y que requieren ser abordados previamente para un correcto entendimiento.

• Recipe: un asistente en el Visual Studio que nos automatiza la creación de algún elemento de CAB/SCSF.
• WorkItemController: con SCSF en lugar de heredar nuestros WorkItems de la clase WorkItem podemos heredar de la clase abstracta WorkItemController, esta clase contiene un workitem asociado al cual podemos acceder por medio de la propiedad WorkItem. De esta forma, logramos una mejor separación de responsabilidades del WorkItem, que anteriormente actuaba como contenedor
  (Items, Services, WorkItems) y como lugar donde se colocaba la lógica de negocio de los casos de uso. Ahora el WorkItem sólo actúa como conteneder y nuestra clase que hereda de WorkItemController es el lugar donde colocamos la lógica de negocio.
• ControlledWorkItem: es una clase genérica (debemos indicarle un WorkItemController) que nos ayuda a instanciar nuestro WorkItem que hereda de WorkItemController.
• Business Module: es un proyecto (DLL) que contiene una unidad del negocio junto con sus vistas (ej. Módulos Clientes, Stock, Administración, etc.). Cada Business Module tienen un WorkItemController principal llamado ModuleController.
• ModuleController: es una clase que hereda de WorkItemController que toma el papel de WorkItem raíz para el módulo de negocio. En esta clase es donde realizaremos gran parte de las
  tareas de inicialización del módulo (agregar vistas, añadir ítems a los extension sites, registrar servicios, etc.).
• Fundational Module: al igual que un Business Module, es una DLL pero generalmente no poseen vistas y no tienen WorkItems. Se emplean, principalmente, para contener servicios globales que utilizan otros módulos (ej. Módulo Logging, Seguridad, Acceso a Datos, etc.). Todos los módulos (tanto fundational como business) tienen una clase Module que hereda ModuleInit con un método Load para que puedan ser cargados por CAB.
• Action Catalog: servicio de SCSF que implementa un patrón que permite ejecutar acciones basado en condiciones que cambian en tiempo de ejecución.
• Disconected Service Agent: SCSF provee un recipe para crear disconnected service agents (DSA). DSA es un servicio que permite abstraer un servicio web para poder usarlo en forma desconectada cuando el servicio no está disponible.
• Entity Translator: servicio de SCSF que permite transformar una entidad de negocio a otro tipo de entidad requerida por servicios externos.

Solución inicial

Cuando creamos un proyecto de SCSF, este nos crea una solución con varios proyectos listos para funcionar que se encuentran organizados en un conjunto de carpetas. Los proyectos iniciales que se
encuentran en la carpeta Infrastructure son proyectos básicos para el funcionamiento de la aplicación y que brindan los servicios sobre los que se construyen los demás módulos que componen la
aplicación. Dependiendo de la configuración que hayamos elegido en la recipe al momento de crear el proyecto, nuestra solución contendrá básicamente los siguientes proyectos:

• Infrastructure.Interface: contiene elementos globales que necesitan ser expuestos a los módulos de la aplicación como ser: interfaces de los servicios de infraestructura, definiciones de constantes, entidades de negocio que necesitan ser pasadas entre varios módulos, etc.
• Infrastructure.Library: contiene las implementaciones de los elementos comunes para todas las aplicaciones SCSF como ser los servicios de trasformación de entidades, del DSA, carga
  del ProfileCatalog desde un Web service, etc.
• Infrastructure.Module: es un business module vacío que podemos usar para la implementación de cualquier elemento que necesita ser compartido por varios módulos de la aplicación.
• Shell: al igual que una aplicación CAB, es el proyecto inicial que tiene el ProfileCatalog.xml para cargar los módulos y crea el WorkItem raíz y contiene el formulario Shell que posee la interfaz básica con los Workspaces para desplegar las vistas.
• Infrastructure.Layout: es un módulo que contiene una vista en la que se diseña la interfaz común
  dejando a la shell prácticamente vacía, logrando una mejor separación de responsabilidades y facilitando el reemplazo y reutilización de la interfaz común de la aplicación. Este proyecto se crea sólo si se tildó la opción para crear un módulo separado para el layout del shell.

Los siguientes pasos, una vez que ya tenemos la solución para comenzar a trabajar, son:

1. Modificar la Shell si la interfaz por default no es lo que necesitamos.
2. Crear los módulos fundacionales que expondrán servicios para el resto de la aplicación.
3. Crear los módulos de negocio, las vistas y demás elementos necesarios.

Si empleamos TDD, luego de crear cada módulo y antes de seguir con la implementación del módulo, debemos crear las pruebas y seguir con el proceso del desarrollo dirigido por pruebas.

Todas estas tareas pueden hacerse en forma automatizada usando las recipes que nos ofrece SCSF.

¿Cómo se hace en SCSF?

Una situación común en la gente que empieza con SCSF es preguntarse cuál es la forma en que se hace determinada cosa en SCSF, o dónde tengo que poner tal cosa o cuál es la forma correcta de hacer tal otra cosa. Ésta desorientación en los principiantes se puede deber a la gran cantidad de guías y lineamientos que ofrece SCSF para hacer las cosas, dando la sensación que en SCSF existe una forma específica de hacer cada tarea para que funcione.

En realidad, SCSF y CAB son una extensión de funcionalidades que nos ayuda a crear mejores aplicaciones siguiendo una limitada selección de prácticas recomendadas, pero no pretende ser la solución perfecta para todas las situaciones posibles.

En una aplicación SCSF se pueden implementar una cosa de mil formas distintas o como lo hacemos siempre en cualquier aplicación y va a funcionar sin demasiados problemas. SCSF sólo nos facilita realizar una limitada cantidad de tareas en una forma organizada.

Sin embargo, cuando somos ajenos a los patrones y prácticas que se utilizan en CAB/SCSF podemos seguir sin saberlo caminos que nos pueden llevar a encontrarnos con dificultados. A continuación sugiero algunos tips que considero pueden ayudar en esta toma de decisiones:

• Utilizar un módulo separado para el layout cuando tengamos mucha lógica de presentación para la interfaz común que no queremos mezclar con las demás responsabilidades del proyecto Shell (el
  proyecto Interface.Layout tiene un ModuleController y el Shell no), o cuando queremos reutilizar la interfaz común o poder “switchearla” dinámicamente (ej. según preferencias del usuario).
• Las vistas deberían contener el mínimo posible de lógica. La gran parte son llamadas a funciones en el presenter para informar de eventos y propiedades y eventos que el presenter usa para. El presenter contiene la lógica para manejar los eventos y actualizar la vista y el modelo.
• Es recomendable siempre usar interfaces (principalmente en vistas y servicios) para poder intercambiar las implementaciones y facilitar el testing.
• Usar siempre constantes para los identificadores de comandos, eventos, extensión sites, etc..
• No usar la misma cadena para identificar un Evento y un Comando. CAB no distingue entre eventos y comandos del mismo nombre y puede traer problemas.
• Crear un WorkItem para contener los datos o información de contexto que necesita ser comunicado a los presenters de las vistas de un módulo. Un error común es pasar información a una
  vista o presenter por medio de los parámetros de un evento (Event Broker), es mejor usar States.
• Utilizar Event Broker cuando se necesita informar de eventos a toda la aplicación sin importar quién lo reciba.
• TDD es una muy buena práctica que SCSF tiene en cuenta.
• Gran parte de la lógica de negocio, incluyendo inicializaciones, comandos, y eventos suelen quedar en los ModuleController, es muy normal.

Pueden existir más recomendaciones, pero lo importante es conocer todos los elementos y herramientas que podamos tener a nuestro alcance y comprender bien cuál es el cometido de cada uno, de esta forma sabremos qué usar en cada escenario y cómo, logrando la combinación más conveniente.

Lecturas recomendadas:

• Designing Smart Clients Based on CAB and SCSF
• Serie de Introducción a CAB/SCSF de Richnewman
• Quick Starts y Hands on Lab en la página oficial
• SCSF Knowledge Base en CodePlex

En este post se pasaron por alto los detalles técnicos del uso de SCSF y que escapan al alcance de este post, para eso recomiendo seguir los Hands on Lab que son muy didácticos para el aprendizaje de este excelente framework.

Ya en mi segunda semana en Southworks he estudiado y aprendido mucho sobre Composite UI Application Block (CAB) y Smart Client Software Factory (SCSF) como parte de mi entrenamiento. En este post voy a resumir parte de lo que he aprendido acerca de CAB con el propósito de que le sirva a alguien más como introducción al tema. Sé que CAB es difícil de aprender debido a que muy pocos están acostumbrados a trabajar con todos los patrones y la arquitectura que CAB propone y por esto trataré de explicar los aspectos fundamentales del mismo en la forma más clara que pueda. En próximos posts seguiré con SCSF y WCSF.

Qué es CAB

CAB es un Application Block creada por el equipo de Patterns & Practices de Microsoft y nos ofrece una librería de clases que nos ayudan a implementar un conjunto de patrones de diseño orientados principalmente a la presentación. CAB nos permite crear aplicaciones Windows denominadas “Smart Client”. Una de las características más sobresalientes de CAB es que las aplicaciones resultantes son modularizadas y con muy poco acoplamiento entre los módulos, esto es logrado básicamente por el extenso uso que hace CAB (con su librería ObjectBuilder) de la inyección de dependencias.

Es importante aclarar que el desarrollo de aplicaciones CAB debería ser realizado partiendo de un diagrama de casos de uso ya que los módulos que compongan la aplicación y sus elementos deberán estructurase según estos. Dentro de cada módulo existen elementos, que describiré más adelante, que implementan los casos de uso casi en una relación uno a uno. Estos elementos y sus casos de uso serán agrupados dentro de los módulos según criterios de seguridad, configuración y reusabilidad.

¿Qué se logra al emplear CAB?

Las aplicaciones creadas usando CAB se destacan por las siguientes características:

• Módulos reusables y con muy bajo acoplamiento,
• facilidad para el desarrollo en equipos (cada equipo desarrolla un módulo sin necesidad de estar al tanto de los demás),
• implementación de patrones de diseño y prácticas probadas y recomendadas (M.V.P., Command, Event Brocker, etc.),
• separación de conceptos (cada módulo tiene bien definida su parte de presentación visual, lógica del dominio de la aplicación y los servicios de infraestructura),
• mantenimiento y extensibilidad (se pueden añadir nuevas funcionalidades o modificar las existente sin mayores inconvenientes. Se pueden remplazar módulos, vistas, implementaciones, etc. sin tener que adaptar los demás componentes),
• “Testeabilidad” (debido a que la vista está separada de la lógica que implementa es muy fácil crear pruebas de unidad automatizadas que validen los Controllers y Presenters).

Estructura de una aplicación CAB

Todas las aplicaciones CAB poseen un proyecto central denominado Shell Application. Este es un proyecto Windows Forms que contiene tres elementos importantes: el primero es el formulario principal (llamado Shell) que contiene el Layout en el cual se mostrarán los componentes visuales denominados SmartParts que no son más que controles de usuario, pero no todos los SmartParts deberán ser desplegados en el Shell, los SmartParts a su vez también pueden mostrar otros SmartParts de otros módulos, pero estos no pueden ser desplegados dentro de cualquier tipo de control, existen unos contenedores especializados que se denominan Workspaces los cuales despliegan los SmartParts en distintas disposiciones.

El otro elemento importante del Shell Application es el WorkItem raíz, los WorkItems son clases que contienen lógica del negocio (ej. de un determinado caso de uso) y que a su vez contienen colecciones de otros WorkItems creando una estructura jerárquica (esta estructura es importante para comprender el alcance de la disponibilidad de los servicios y demás elementos que serán compartidos), pero también pueden contener colecciones de Servicios, Comandos, SmartParts, y otros ítems. Los WorkItems deben implementarse heredando de la clase WorkItem pero no es necesario en la aplicación Shell, se puede emplear directamente la misma clase.

El último elemento es un archivo de configuración llamado ProfileCatalog.xml en el cual se especifican los módulos que deberán ser cargados a la aplicación.

<?xml version="1.0" encoding="utf-8" ?>

<SolutionProfile xmlns="http://schemas.microsoft.com/pag/cab-profile" >

<Modules>

<ModuleInfo AssemblyFile="ModuloA.dll" />

<ModuleInfo AssemblyFile="ModuloB.dll" />

</Modules>

</SolutionProfile>

Luego la solución deberá componerse de un conjunto de Módulos que implementarán la lógica de los casos de uso y las funciones de infraestructura como acceso de servicios web, acceso a datos, etc.

Los módulos son proyectos de librería de clases que pueden contener: servicios que exponen funcionalidades, WorkItems, vistas (SmartParts) con sus respectivos Presenters o Controllers, y por último todos los módulos deberán contener una clase que herede de ModuleInit, esta clase es el punto de entrada al módulo (al cargar un módulo CAB buscará esta clase) y es la encargada de las tareas de la inicialización y configuración inicial del módulo.

Características importantes

Los elementos que detallaré a continuación son algunas características de CAB que permiten la comunicación entre los componentes de la aplicación pero manteniendo un bajo acoplamiento entre los mismos.

Workspaces

Como se describió anteriormente un Workspace es un control que permite desplegar en el mismo los elementos visuales denominados SmartParts. En esta sección lo que se pretende aclarar es que cada WorkSpace tiene un nombre asignado por medio del cual los demás elementos pueden hacer referencia al mismo y así poder desplegar los SmartParts. Los WorkItems poseen una colección Workspaces por medio del cual acceden a los Workspaces. Esta los valores de esta colección es inyectada por CAB.

UIExtensionSites

Un UIExtensionSite es una colección de sitios donde se pueden agregar, quitar, habilitar y deshabilitar dinámicamente ítems de un componente visual como ser menús, botoneras, etc.. Cada elemento del UIExtensionSite es un componente visual fijo que no será modificado salvo por sus elementos hijos (submenús, botones) y estos sitios son referenciados por un nombre (ej. “MainMenu”). Esto puede ser muy útil por ejemplo cuando un módulo necesita añadir una nueva opción en el menú principal de la aplicación para invocar la funcionalidad que el módulo añade.

Ejemplo para registrar un UIExtensionSite:

RootWorkItem.UIExtensionSites.RegisterSite(“FileMenu”, Shell.MainMenuStrip);

Ejemplo para añadir un item a un UIExtensionSite:

ToolStripMenuItem printItem = new ToolStripMenuItem(”Print”);

RootWorkItem.UIExtensionSites[“FileMenu”].Add(printItem);

Publicación y subscripción de eventos

La publicación de eventos es un mecanismo que nos permite publicar eventos y subscribirse a los mismos, de esta forma no existe un acoplamiento directo entre la declaración del evento y su handler pudiéndose crear y quitar eventos sin necesidad de modificar sus manejadores. Cada evento es identificado por una especie de URI donde se define el tema y el nombre del evento.

Ejemplo de publicación de evento:

[EventPublication("topic://BankShell/statusupdate", PublicationScope.Global)]

public event EventHandler<DataEventArgs> UpdateStatusTextEvent;

Ejemplo de subscripción a un evento:

[EventSubscription("topic://BankShell/statusupdate", Thread = ThreadOption.UserInterface)]

public void OnStatusUpdate(object sender, DataEventArgs e)

{

toolStripStatusLabel1.Text = e.Data;

}

Comandos

Es muy común que las aplicaciones contengan más de un modo de ejecutar una determinada función (ej. menú Edición -> Cortar, Botón con ícono de tijera, menú contextual -> Cortar), los comandos nos permiten registrar métodos que podrán ser invocados desde varios lugares, esos lugares son eventos añadidos como invocadores del comando.

Ejemplo de un comando:

[CommandHandler(CommandConstants.EDIT_COPY)]

public void OnEditCopy(object sender, EventArgs args)

{

//…

}

Los comandos son implementados en los Controllers.

Ejemplo para añadir un evento a un comando:

Commands[CommandConstants.EDIT_COPY].AddInvoker(editCopyMenuItem, “Click”);

Servicios

Los servicios son clases que exponen funcionalidades a los demás componentes de la aplicación como ser Web Service Agents, logging, autenticación, etc.. Un servicio se define marcando una clase (no necesita heredar nada) con el atributo [Service], luego los servicios pueden ser inyectados por medio de una propiedad del mismo tipo marcada con el atributo [ServiceDependency] o por medio de la colección Services de un WorkItem.

Glosario CAB

A continuación se incluye un catálogo de los elementos más importantes que componen una aplicación CAB con el fin de aclarar conceptos:

Shell Application: es la aplicación principal que se inicia primero y que es responsable de la inicialización, carga de los módulos, inicializar los servicios base/globales e iniciar el formulario principal (Shell).

Shell: es el formulario principal que contiene la interfaz común a todos los módulos. Además, aloja el WorkItem raíz que será el punto de entrada para las demás partes de la aplicación.

ProfileCatalog: es un documento xml en el que se configuran los módulos y servicios que deben ser cargados.

WorkSpace: son controles que permiten alojar y desplegar los elementos de interfaz (SmartParts) que son creados por los WorkItems.

UIExtensionSite: son contenedores especiales para extender partes fijas del Shell como por ejemplo: menús, botoneras, barra de estado.

Module: un proyecto de librería de clases que encapsula un conjunto de WorkItems.

ModuleInit: es una clase que tienen todos los módulos y que sirve como punto de entrada. Este es responsable de cargar todos los servicios y WorkItems del módulo además de otras tareas de inicialización y configuración.

WorkItem: una clase que encapsula un caso de uso y mantiene todos los estados de las partes involucradas en el caso de uso. También puede ser visto como un contenedor para gestionar objetos requeridos para realizar una tarea.

Service: es una clase que encapsula funcionalidad que es común a toda o a una parte de la aplicación, módulo o jerarquía de WorkItems.

SmartPart: es un control de usuario marcado con el atributo [SmartPart] y son partes visuales de la aplicación.

Model: es una entidad del negocio del lado del cliente que es procesada por un WorkItem.

View: un control de usuario responsable de mostrar una parte del modelo al usuario. Sólo implementa lógica de UI, la lógica del negocio es implementada por el Controller o el Presenter.

Controller: una clase que implementa lógica para modificar un modelo que puede ser presentado por varias vistas.

Presenter: una clase que implementa lógica de negocio para una sola vista.

Command: clase base para implementar el patrón Command. Los comandos se declaran con el atributo [CommandHandler] y luego se le asignan los múltiples invocadores.

EventPublication: permite publicar eventos con bajo acoplamiento. Los eventos se marcan con el atributo [EventPublication] con un identificador tipo URI y luego serán notificados los suscriptores con el mismo URI.

EventSuscription: permite suscribirse a eventos publicados con EventPublication, se marcan los manejadores del evento con el atributo [EventSuscription] y con el mismo URI del evento al que suscribe.

¿Cómo usar CAB?

Actualmente existe un proyecto llamado Smart Client Software Factory el cual brinda un conjunto de herramientas que facilitan enormemente la tarea de implementar una aplicación Smart Client con CAB por medio de un conjunto de asistentes, guías, hows to, clases adaptadas, etc.. Por eso, si deseas crear una aplicación con CAB te recomiendo que sigas con el siguiente paso (SCSF) en lugar de lidiar con una implementación de CAB desde cero.

Enlaces relacionados

Todos los nuevos conocimientos que se adquieren son reforzados mediante la puesta en práctica por eso recomiendo seguir los Hands on Lab y los QuickStarts que vienen con la instalación de CAB.

Documentación oficial

CabPedia

Designing Smart Clients with the Composite UI Application Block & the Smart Client Software Factory

Excelente serie de artículos sobre CAB/SCSF