El framework de coco

No te acostaras sin saber una o dos cosas mas ...

La Capa de Presentación : Conceptos Básicos

A día de hoy no conozco ninguna aplicación que pueda utilizarse sin una interfaz de usuario, y aunque parezca curioso, muchos arquitectos tienden a encasillar a la interfaz de usuario como la parte más aburrida en el desarrollo y sin embargo en muchos proyectos es donde más tiempo de emplea.

La capa de presentación es a menudo la última parte que se despliega y tiende a ser muy dependiente de las herramientas de desarrollo utilizadas, sin embargo la capacidad de desenchufar una interfaz de usuario y reemplazarla con otra suele ser un requerimiento clave en todas las capas de presentación.

La implementación de un capa de presentación puede ser muy sencilla, pero hay escenarios donde se puede volver muy compleja mediante el uso de maestros, detalles y flujos de navegación.

A grandes rasgos se podría decir que la capa de presentación se compone de :

  1. La interfaz de usuario
  2. La lógica de presentación

La interfaz de usuario ofrece a los usuarios información, sugerencias, acciones y captura los datos de entrada a través del teclado y el ratón.

La lógica de presentación hace referencia a todo el procesamiento requerido para mostrar datos y transformar los datos de entrada en acciones que podemos ejecutar contra la capa de negocio o de servicios.

Se podría decir que la lógica de presentación esta muy relacionada con mostrar datos en la pantalla del usuario.

 DiagramaCapaPresentacion.JPG

Como se puede observar en la imagen, la capa de presentación es la interfaz entre el usuario y el sistema.

Si le preguntamos a alguien sobre cuales son las responsabilidades de la capa de presentación seguramente nos responderá con algunas de estas :

El estilo y la usabilidad pueden considerarse simples atributos, y la validación y formateo pueden implementarse mediante componentes.

Todas estas “responsabilidades” suelen estar estrechamente relacionadas con la tecnología y plataforma elegida para implementar el sistema.

Una capa de presentación a alto nivel tiene tres grandes responsabilidades :

  1. Independencia de la interfaz de usuario
  2. Testeabilidad
  3. Independencia del modelo de datos

Seguramente nos habremos encontrado más de una vez con el siguiente dilema :

El caso es que la capa de presentación debe ser capaz de escalar todas estas incognitas sin que la lógica de presentación se vea afectada, un claro ejemplo de ello son las aplicaciones de blogs como el que estais leyendo ahora mismo.

La capa de presentación también debe ser independiente de la tecnología de interfaz de usuario y plataforma usadas, aunque este requerimiento es muy complicado de cumplir y en la mayoría de las ocasiones es imposible obtener una independencia total.

Para conseguir desacoplar la interfaz de usuario de la lógica de presentación  debemos hacer uso de contratos de datos, para entenderlo mejor imaginemos el siguiente formulario web de visualización y entrada de datos :

EjemploInterfazUsuario.JPG

A grandes rasgos, tenemos :

Si aplicamos un buen diseño en la capa de presentación nuestro contrato de datos para el formulario estará formado por la siguiente interfaz :

public interface IViewGarmentIncidence
{
    Employee Employee { get; set; }

    IList<Garment> Garments { get; set; }

    int IncidenceGarmentType { get; set; }

    int GarmentType { get; set; }

    int Size { get; set; }

    string Details { get; set; }

    int Amount { get; set; }

    string Comments { get; set; }
}

Mediante el uso de contratos podemos reutilizar la lógica de presentación en otras interfaces de usuario, de este modo podremos implementar por ejemplo, el mismo formulario usando formularios Windows, Silverlight o WPF de tal manera que nuestra única preocupación será implementar la interfaz de usuario con la tecnología seleccionada.

La capa de presentación debería ser probada al igual que el resto de capas, una de las ventajas de conseguir desacoplar la lógica de presentación de la interfaz de usuario, es que podemos probarlas por separado.

Aunque no es fácil probar la interfaz de usuario dentro de un entorno de testing, si que podemos mover todo el código testeable correspondiente a los manejadores de eventos a métodos dentro de una clase.

Un arquitecto no debe implicarse directamente en la definición de los detalles de la interfaz de usuario, en su lugar, debe preocuparse de la definición de los datos que se manejaran en cada formulario y  de aspectos de calidad como por ejemplo la usabilidad y la accesibilidad.

Una vez que el arquitecto ha definido con éxito los datos que se manejaran en cada formulario con los usuarios del sistema, el equipo de desarrollo puede proceder a implementar y probar la lógica de presentación al mismo tiempo que los diseñadores gráficos se ocupan de desarrollar la interfaz de usuario.

Y eso es todo por hoy, en el siguiente post hablare sobre el patrón Modelo Vista Presentador, de sus ventajas e implementación.