Composite UI Application Block - Conceptos

Fri, 22 Dec 2006 14:05:55 GMT

Voy a comenzar una serie de tutoriales básicos sobres el desarrollo de smart client applications utilizando el CAB (Compisite UI Application Block) del equipo de Patterns&Practices de Microsoft. Como todo tutorial, este pretende solo brindar un entendimiento general de las potencialidades del CAB y algunos elementos prácticos iniciales para facilitar la introducción a este Application Block (en adelante AB) que muchos consideran dificultoso de entender y que es uno de los AB centrales del Smart Client Software Factory (SCSF).

Objetivo del CAB

El CAB, como su nombre lo indica, es un application block diseñado para ayudar en la tarea de desarrollo de aplicaciones Windows Form-based. Esto gracias a que provee una serie de patrones comunmente encontrados en aplicaciones windows front-end. Uno de los mas importantes objetivos es permitir el desarrollo de módulos totalmente independientes pero a la vez colaborativos.

Lo que el CAB NO es

Es importante aclarar que el CAB no es:

Una libreria de controles
Una herramienta para diseñar formularios
Un producto propiedad de microsoft

Pros y Contras

Las ventajas de su uso se obtienen si se trabaja en equipo donde distintas personas desarrollan módulos independientes de una aplicación smart client form-based en donde la complejidad de la interface de usuario es elevada. Es indispensale contar con un conocimiento profundo del AB antes de embarcarse en un proyecto con este pues los subsistemas de inyección de dependencias y eventbroker, sumados a los cambios en el paradigma de desarrollo de aplicaciones windows que introduce el CAB pueden hacer fracasar el proyecto o colaborar en la definición de una arquitectura erronea.

El CAB introduce cierta complejidad a los proyectos por cuanto es rico en conceptos nuevos que deben dominarse y en partes componentes de los módulos. Además las aplicaciones desarrolladas con este son un poco mas difíciles de depurar.

Comenzamos

Primero voy a definir algunos términos que verán en forma recurrente en este y en cualquier artículos sobre el tema. Estas definiciones serán muy sencillas con el objetivo de brindar un entendimiento rápido de aquellos que definen los componentes de la arquitectura proporcionada por el CAB. Con esta sencillez se pierde un poco de realismo pero iré profundizando los conceptos a medida que avance y requiera mayor precisión. Mostraré primero aquellos términos que son facilmente identificables por ser visibles o estar directamente relacionados a la composición de los formularios windows.

Smartpart: Sencillamente se trata de un UserControl. Por ejemplo un Smartpart de datos de clientes o formulario de pedido.
View: es otro nombre utilizado en forma intercambiable por Smartpart. Este cobra mayor sentido cuando se encuentra en el contexto de la implementación del patrón Model-View-Controller.
Workspace: Es un Control contenedor muy similar a un Panel que se utiliza para armar el layout de los forms de la aplicación. Estos workspaces (contenedores) contendrán los Smartparts que se visualizarán.
UIElements: son, y perdonen la obviedad, elementos de la interface de usuario comunes a toda una aplicación. Por ejemplo los menues, barra de estados y barra de herramientas. Estos elementos deben compartirse entre lós módulos de la aplicación.
SmartPartPlaceholders: es solo un control que actua como contenedor de un SmartPart.
Layouts: son UserControls que mediante Workspaces y/o SmartPartPlaceholders determinan la distribución de los SmartParts en el formulario.
Shell: la diferencia entre Shell y Modules la explico mas adelante.

Modules: son assembies que contienen los necesario (Workitems, Smartparts, Controllers, States, Services, etc) para implementar una funcionalidad específica. Por ejemplo, módulo de clientes, módulo de facturación, módulo de stock, etc.
Workitem: entendamoslo como una "pieza de trabajo". Es "SOLO un contenedor" que aloja todos los componentes necesarios para cumplir con una pieza de trabajo. Es decir, contiene los Smartparts, Controllers, States, Services, Commands, Items, Workspaces y otros Workitems. Es como una gran bolsa donde guardamos todo lo necesario para realizar una tarea. Por lo general es util pensar en la pieza de trabajo como un Use Case, así por ejemplo podemos pensar el un workitem AltaPacienteWorkItem, RechazoPolizaWorkItem o ConsultaCreditoWorkItem aunque no tiene por qué corresponder si o si a un caso de uso.
Controllers: son simplemente los controladores en el caso de una implementación del patrón Model-View-Controller.
States: cada workitem contiene una colección no tipada de objetos (es decir, una colección que puede tener objetos de cualquier tipo) para guardar aquellos objetos necesarios para realizar la tarea. Por ejemplo, si el workitem es PagoServicioWorkItem (un workitem creado por nosotros para realizar el pago de un servicio cualquiera como agua, luz, gas, iternet, etc), la colección States de este workitem contendrá las instancias de los objetos que intervienen en el pago de un servicios como son, el usuario del servicios, el prestador, el recibo, el contrato, y algunos otros mas.

Hemos dividido estas definiciones en dos grupos, los que tienen relación diracta con la composición de los formularios y los que no. Esto es porque el CAB se compone de tres assemblies:

Microsoft.Practices.CompositeUI.WinForms.dll - el primer grupo
Microsoft.Practices.CompositeUI.dll - el segundo grupo
Microsoft.Practices.ObjectBuilder.dll -recomiendo que lean el último post relacionado Dependency Injection with ObjectBuilder

Shell y Modules

Supongo que el concepto de módulo es lo bastante intuitivo y/o familiar como para definirlo. Solo diré que una aplicación se puede dividir en móulos. Por ejemplo un CRM puede dividirse en Contactos, Productos, Leads, Oportunidades, Actividades, Casos, etc.

Ahora, el Shell es la aplicación marco que contiene los elementos de interface de usuario común a todos los módulos y que es la encargada de cargar los módulos. Por esto, toda solución en la que se utilice el CAB contendrá al menos dos proyectos, uno ejecutable (el Shell .exe) y al menos un módulo class library (el/los módulo/s .dll).

La idea detrás de esto es no solo la separación e independencia de los módulos entre si, sino también la posibilidad de que distintos equipos desarrollen módulos en forma paralela.