Funcionalidades capa de presentación

LIBP-0011 (Libro de pautas)

La programación por capas es un estilo de programación en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño

Un ejemplo básico de la programación por capas consiste en separar la capa de datos de la capa de presentación al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado.

La capa de presentación es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (comprensible y fácil de usar) para el usuario.

Pautas

TítuloCarácter
Separación de la lógica de negocio y presentaciónObligatoria
Desacoplamiento entre capasObligatoria
Aspecto gráfico externoObligatoria
Modularidad de la vistaObligatoria
InternacionalizaciónRecomendada
Validaciones en la capa de presentaciónObligatoria
Conversiones en la capa de presentaciónObligatoria
Evitar la lógica en la interfazObligatoria
Elaborar un catálogo de controlesRecomendada
Gestión de los mensajesObligatoria

Separación de la lógica de negocio y presentación

La vista se debe limitar únicamente a la presentación de información al usuario o a solicitársela, nunca deberá procesar ni tomar decisiones sobre ella, que serán competencias de las capas superiores de la aplicación. No se permiten operaciones para el procesamiento de datos.

Una vista web presentará datos al usuario. Estos resultados se obtendrán de procesos con capas inferiores que serán las encargadas de procesar los datos. Esta capa requerirá interacción por parte del usuario en forma de formularios que rellenar o botones/enlaces que activar.

Desacoplamiento entre capas

La capa vista sólo puede contener lógica de visualización.

Las clases de acción (Action o Controller) deben contener sólo lógica de presentación. Deberá evitarse el acoplamiento de las capas de la aplicación, es decir, cada capa debe tomar la responsabilidad que le corresponde.

En este caso, debe evitarse que la capa de presentación realice atribuciones que le correspondan a otras capas.

Por ejemplo:

  • Las vistas sólo pueden contener lógica de visualización. Al no permitirse scriptlet en las JSPs, la posibilidad de inyectar lógica de negocio o persistencia en las JSPs disminuye.
  • Las clases de acción (Action en Struts, Controller en JSF) deben contener sólo lógica de presentación. Por ello, no deberían tener una gran carga de desarrollo; invocarán a clases de la lógica de negocio que encapsulen buena parte del código. En ningún caso debería haber lógica de persistencia en los Action o Controller.

Aspecto gráfico externo

Todas las aplicaciones que se desarrollen deben seguir el mismo aspecto gráfico externo, a nivel de proyecto, corporativo y de función de negocio.

El aspecto podemos separarlo en dos consideraciones: una relativa al aspecto general de las pantallas (distribución de la pantalla, uso de cabecera, pie, cuerpo) y otro relativo al aspecto de los componentes/controles de cada pantalla (botones, campos de entrada, etc.)

El primer aspecto no debe influir en el proceso de construcción de la vista: si se construye una vista para presentar datos a un usuario, ésta no debe verse afectada por la posición dentro de la pantalla en la que será ubicada.

El segundo aspecto sí influye en la construcción, de ahí que los tipos de letra, los botones, representación visual de ciertas propiedades de los controles, aspecto de mensajes de error, etc., deben estar totalmente parametrizados mediante hojas de estilo CSS. En general, se debe poder modificar el aspecto final de una página (estructura o estilo visual) sin necesidad de tener que modificar el código fuente.

Modularidad de la vista

Cada página para una función de negocio que se realice no debe hacer referencia a nada que no esté relacionado con su propia funcionalidad, siendo decisión del framework, una vez en ejecución, integrar la página entre la cabecera, pies y menú que le corresponda, aumentando así la reusabilidad de las páginas y el encapsulamiento de funcionalidad.

Internacionalización

Las aplicaciones deben estar preparadas para que puedan adaptarse a diferentes idiomas y convenciones (formatos de fecha, moneda, etc.) sin necesidad de realizar cambios en el código. Esto se consigue con la internacionalización (i18n).

Validaciones en la capa de presentación

MADEJA recomienda realizar validaciones sobre los datos introducidos por los usuarios en la capa.

La vista será la responsable de la primera validación de los datos introducidos por los usuarios. Las validaciones deben ser solo de obligatoriedad de campos y validaciones formales. Nunca deberá realizarse una validación de negocio desde esta capa. La validación de campo obligatorio no va asociada al tipo de dato, sino a la función que se está codificando, por ello este tipo de validación se reflejará directamente en la página. En cambio, las validaciones de formato sí son independientes del contexto de la función.

Conversiones en la capa de presentación

Los formularios JSF recogen entradas de usuarios en forma de cadenas de caracteres. Estas cadenas para su uso en el interior de la aplicación, se deben convertir a los objetos adecuados, bien tipos base de Java (integer, long, double, boolean) o bien tipos complejos propios de la aplicación. Aquí se pueden encontrar dos situaciones:

  • Algunos objetos de negocio complejos u objetos intermedios (objetos que se usen en la capa de presentación como un previo al paso de datos a la capa de negocio) se podrán incorporar directamente en las páginas. Para esto se asignarán conversores en los campos cuyo valor se vaya a usar para crear o modificar estos objetos de negocio complejos.
  • Clases conocidas, bases de java, con las que se trabajará directamente en la aplicación y que necesitan conversión desde y hacia cadenas de caracteres: números decimales, fechas…

En el primer caso será necesario crear en el proyecto los conversores apropiados normalmente, aunque pueden reutilizarse los que nos ofrezca el framework con el que implementemos la capa, mientras que en el segundo caso es más normal que puedan usarse los conversores que provee el framework en su especificación.

Evitar la lógica en la interfaz

Es recomendable elaborar un catálogo con la lista de controles oficiales. En ella estará totalmente especificada la función del control, los posibles validadores/conversores que se le puedan asociar, los eventos que pueda lanzar y los atributos que puedan cambiarse para manipular su aspecto externo.

Los controles deben permitir el tratamiento como componentes Java que junto con el tratamiento de eventos nos posibilita el extraer de la vista toda la lógica de interfaz.

La consecuencia principal de este enfoque es que desde la vista nunca se manipularán los controles. El objetivo es que la construcción de la vista sea una tarea totalmente autónoma del resto de componentes de la función de negocio (básicamente de los beans de respaldo) y luego todas las piezas se integren perfectamente sin grietas.

Elaborar un catálogo de controles

Es recomendable elaborar un catálogo con la lista de controles oficiales. En ella estará totalmente especificada la función del control, los posibles validadores/conversores que se le puedan asociar, los eventos que pueda lanzar y los atributos que puedan cambiarse para manipular su aspecto externo.

Los controles deben permitir el tratamiento como componentes Java que junto con el tratamiento de eventos nos posibilita el extraer de la vista toda la lógica de interfaz.

La consecuencia principal de este enfoque es que desde la vista nunca se manipularán los controles. El objetivo es que la construcción de la vista sea una tarea totalmente autónoma del resto de componentes de la función de negocio (básicamente de los beans de respaldo) y luego todas las piezas se integren perfectamente sin grietas.

Gestión de los mensajes

Los mensajes que las aplicaciones devuelvan estarán a tres niveles:

  • Mensajes provenientes de los controles.
  • Mensajes resultado del proceso de datos por parte del bean de respaldo.
  • Mensajes provenientes de la capa de negocio.