¿Que Código pongo en mi Capa de UI ?

Esta es una pregunta constante que recibo vía blog, o cuando estoy trabajando en el diseño de alguna arquitectura en algún cliente. Normalmente, los desarrolladores comprenden bien de que se trata este asunto de las arquitecturas n-layer, comprenden que poner en la capa de acceso a datos, y tienen una idea general de lo que debe llevar la lógica de negocios. Pero cuando se habla de la capa de presentación hay serias dudas.  Estas dudas se dan principalmente porque estamos acostumbrados a escribir código en las pantallas de nuestras aplicaciones sin cuestionarnos si ese código debería ir en las pantallas – web, mobile, desktop – o no.

Para poder contestar esta pregunta, primero tenemos que entender que código debemos poner en las demás capas. De manera resumida, podemos decir que en la capa de acceso a datos vamos a escribir todo el código necesario para poder acceder nuestro repositorio de datos. Escribimos en esta capa las funciones para consultar, borrar, actualizar o ingresar datos, el código para conectarse a la base de datos y todo los relacionado con la interacción con los repositorios a los que accede nuestra aplicación. En la capa de lógica de negocios escribimos el código relacionado con el proceso que vamos a automatizar. Los objetos de negocio que tengan atributos ( cuando no dividimos el estado del objeto del el comportamiento ) tienen reglas de negocio en sus propiedades e incluso validaciones de asignación o retorno del dato en la propiedad. Nunca se debe acceder el estado del objeto directamente accediendo al atributo, siempre se deben utilizar métodos o propiedades. El siguiente diagrama nos muestra la composición de una instancia de un objeto de negocio y como se debe cambiar el estado del objeto.

Si se tiene capa de servicios, en esta capa no debe de tener código de lógica de negocios solamente invocación a componentes de negocio, esto principalmente porque si hay algún cambio a nivel del negocio, todas las interfaces que consumen esa lógica de negocios van a ver reflejado el cambio, sin importar si la consumen via servicio o directamente al componente.

Después de repasar que código poner en cada capa, nos queda solamente indicar que código realmente debemos tener en el UI:

• Excepciones: Se deben de atrapar los errores que se presenten a nivel de interfaz gráfica y presentar al usuario un error que sea comprensible y que no asuste al usuario
• Validaciónes: En la capa de UI deben de existir validaciones respecto a la interacción del usuario con la aplicación.
• Databinding: Se agrega el código necesario para permitir el databinding entre los datos que despliegan controles del UI y que retornan las capas subyacentes.
• Invocación a la capa de servicios o a la lógica de negocios: Deben de agregarse el código necesario para poder invocar la lógica de negocios de los componentes que estamos utilizando, ya sea a través de la capa de servicios o a través de la lógica de negocios directamente.

Y ahora se preguntarán: ¿En qué me beneficia esto? Pues esto nos va a permitir tener una separación real de capas, con lo que podemos cambiar de tipo de UI sin necesidad de modificar la aplicación, ya que la misma lógica de negocios se va a consumir sin importar el tipo de aplicación que queremos implementar. Si vemos con detenimiento el tipo de código que tenemos que poner en el UI, nos vamos a dar cuenta que por lo general es en estas secciones en donde existen variaciones entre los diversos tipos de UI, por ejemplo, el manejo de eventos para validar e invocar funcionalidad entre una aplicación desktop, una aplicación web, una aplicación mobile y una aplicación RIA.

Technorati Tags: Architecture,n-layer