2. Construcción de Componentes Modelo

"Si yo tengo un mundo a mi disposición, todo sería absurdo. Nada seria lo que es, porque  todo seria lo que no es. Y un sabio contrario, que es, no seria. Y que esto no seria, esto seria. Lo ves?"

2.1 Visión General

Muchos documentos de requerimientos son usados para construir aplicaciones web enfocados en la Vista. Sin embargo, debes asegurar que el proceso requerido para cada solicitud es enviada es claramente definida desde la perspectiva del Modelo. En general,  el desarrollador de los componentes Modelo será centrándose sobre la creación de clases JavaBeans que soporten todos los requerimientos funcionales. La naturaleza precisa de los beans requeridos por una aplicación en particular variará ampliamente dependiendo sobre estos requerimientos, pero ellos  pueden generalmente ser clasificados dentro de varias categorías discutidas abajo. Sin embargo,  una breve reseña del concepto de "alcance" lo que se refiere a beans y JSP es útil.

2.2 JavaBeans y Enfoques

Dentro de una aplicación web, los JavaBeans pueden ser almacenados en (y acceder desde) un numero de colecciones diferentes de "atributos". Cada colección tiene diferentes reglas del tiempo de vida de esta colección y la visibilidad de los beans almacenados ahí.  Juntos, las reglas definiendo el tiempo de vida y la visibilidad son llamados el alcance de estos beans. Las Especificaciones de las Páginas JavaServer definen las opciones de alcance usando los términos siguientes(con el equivalente concepto API servlet definido en paréntesis):

• page - Bean que es visible dentro de una página JSP, por el tiempo de vida de la solicitud actual.(Variables locales del método service)
• request - Beans que esta disponible dentro de una página JSP, así como cualquier página o servlet que sea incluido en la página o remitido por esta página.(Atributos de solicitudes)
• session - Beans que esta visible a todas las páginas JSP y servlets que participan en una sesión  particular del usuario, a través de una o mas solicitudes.(Atributos de Sesiones)
• application - Beans que esta visible a todas las páginas JSP y servlets que son parte de una aplicación web.(Atributos de contextos servlets)

Es importante recordar que las páginas JSP y servlets en la misma aplicación web comparten el conjuntos de colecciones bean. Por ejemplo, un bean almacenado como un atributo solicitud en un servlet como este:

MyCart mycart= new MyCart(...);

request.setAttribute("cart",mycart);

es inmediatamente visible a la página JSP el cual este servlet adelantado, usando un tag accion estandar como este:

<jsp:useBean id="cart" scope="request"

class="com.mycompany.MyApp.MyCart"/>

2.3 ActionForm Beans

Nota: Mientras un beans ActionForm a menudo tienen propiedades que corresponden a propiedades en el bean Modelo, el bean form ellos mismos deben ser considerados un componente Controlador. Como tal, hay la capacidad para transferir información entre las capas Modelo y Vista.

El framework Struts generalmente asume que tiene definido un bean ActionForm(que es, una clase Java extendiendo la clase ActionForm) para la foms de entrada en la aplicación. Los beans ActionForms son alguna veces solamente llamados "form beans".  Estos pueden ser objetos finamente cristalizados, así que hay un bean para cada form o toscamente cristalizado de modo que  un bean sirve a varias form o aun a una aplicación entera.

Si declaras tal como los bean en el archivo de configuración Struts(ver Escribir Mapeo Action), el controlador servlet Struts automáticamente ejecutará los siguientes servicios por ti, antes de invocar el método Action apropiado:

• Chequeo para una instancia de un bean de la clase apropiada, debajo de la llave apropiada, en el apropiado alcance(solicitud o sesión).
• Si hay no muchas instancias bean  disponibles, un nuevo es automáticamente creado y añadido al alcance apropiado(solicitud o sesión).
• Por cada parámetro de solicitud cuyo nombre corresponde al nombre de una propiedad en el bean, el correspondiente método setter será llamado. Estos manejos en una manera similar a la acción estandar JSP <jsp:setProperty> cuando usas el comodín asterisco para seleccionar todas las propiedades.
• El bean actializado ActionForm será pasado por el método execute de una clase Action [org.apache.struts.Action], de modo que los valores pueden estar disponibles en el estado del sistema y los beans de la lógica de negocios.

 Para mas acerca de codificación Actions y beans ActionForm, ver la sección Construcción de Componentes Controladores.

Deben tener en cuenta que un "form"(en el sentido discutido aqui) no necesariamente corresponde a una simple página JSP en la interface de usuario. Es común en muchas aplicaciones tener un "form" (desde la perspectiva del usuario) que extienda varias páginas múltiples. Pensar, por ejemplo del estilo del asistente de la interfaz de usuario es comunmente usado cuando instalamos nuevas aplicaciones. Struts alienta definir un simple bean ActionForm que contiene propiedades para todos los campos, no importando cuales páginas el campo es actualmente mostrado. Asimismo, varias páginas del mismo form deben ser todos enviados a la misma Clase Action. Si sigues estas sugerencias, la página diseñada puede reorganizar los campos a través de varias páginas, a menudo sin requerir cambios en la lógica de procesamiento.

Aplicaciones pequeñas podrían solo necesitar un simple ActionForm para el servicio de todas las entradas forms. Otras aplicaciones usaría una simple ActionForm para cada subsistema importante de la aplicación.  Algunos equipos preferirían tener una clase ActionForm separada por cada entrada form distinta o flujo de trabajo. Cuantas o cuan pocos ActionForms  lo utilizan. Al framework no le importa.

2.4 Estados de Sistemas Beans

El estado actual de un sistema es normalmente representado como un conjunto de uno o mas clases JavaBeans, cuyas propiedades define el estado actual. El sistema de un carrito de compras, por ejemplo, incluirá un bean que represente el carrito siendo mantenido por cada comprador individual y (a través de otras cosas) incluir un conjunto de artículos que el comprador tiene actualmente seleccionado para la compra. Separadamente el sistema también incluirá deferentes beans para la información del perfil del usuario(incluyendo su tarjeta de crédito y direcciones de envío) como el catálogo de artículos disponibles y los niveles de inventarios actuales.

Para sistemas de escala pequeños o sistemas de información que no necesiten mantener un largo periodo de tiempo, un conjunto de beans de sistemas de estado podrán contener todo el conocimiento que el sistema aun  tiene en detalles particulares.  O como a menudo es el caso, el bean de sistema de estado representará información que almacene permanentemente en una base de datos externa(tal como un objeto CustomerBean que corresponde a una columna en particular en la tabla CUSTOMERS) y son creados o removidos desde la memoria del servidor como sea necesario. Entity Enterprise JavaBean son usados para este propósito en aplicaciones de de larga escala.

2.5 Lógica de Negocio Beans

Debes encapsular la lógica de la aplicación como llamadas de métodos en el diseño de JavaBeans para este propósito. Estos métodos pueden ser parte de la misma clase usadas para el beans de estado del sistema o ellos deben ser separado en clases dedicadas para la ejecución de la lógica. En este último caso usualmente necesitarás pasar al bean de sistema de estado para manipular estos métodos como argumentos.

Para un máximo reuso de código, el beans de lógica de negocios debe ser diseñado e implementado así que ellos no lo saben lo que esta  siendo ejecutado en el ambiente  de la aplicación web. Si encuentras tu mismo teniendo que importar una clase javax.servlet.* en tu bean, estas atando esta lógica de negocios al ambiente de la aplicación web. Considera reordenar las cosas a tus clases Action (parte del rol de Controlador, como se describe abajo) traducir toda la información requerida desde la solicitud HTTP siendo procesada dentro de las llamadas de  las propiedades setter sobre el bean de lógica de negocio, después el cual una llamada a un método execute puede ser hecho. Tal una clase de lógica de negocios puede ser reusada en otros ambientes de la aplicación web por la cual eran inicialmente construidos.

Dependiendo en la complejidad y alcance de la aplicación, el bean de la lógica de negocios sería un JavaBean ordinario que interactúa con el bean del sistema de estado pasando  como argumentos o un JavaBean ordinario que accesa a la base de datos usando llamadas JDBC. Para aplicaciones largas, estos bean a menudo serian en lugar de con o sin estado Enterprise JavaBean(EJBs).

Para mas acerca del uso de base de datos con tu aplicación, ver Acceso a Base de Datos HowTo.

Para mas acerca de la lógica de negocios y framework de acceso de datos, ver  llaves de teconologias primarias.

2.5.1 DynaBeans

DynaBeans combina la extensibilidad con la flexibilidad de un Mapa. Definiendo aun lo mas simple JavaBean requiere definir una nueva clase y codificación a un campo y dos nuevos métodos para cada propiedad. Las propiedades de un DynaBean puede ser configurada vía el descriptor XML. Las propiedades virtuales de un DynaBean no pueden ser llamados por métodos estandar Java, pero trabajan muy bien con componentes que confían en reflección e introspección.

En la aplicación , puedes usar DynaBeans para describir en la forms HTML. Esta estrategia puede evitar crear una subclase JavaBean formal para almacenar unas pocas propiedades simples.

Para mas acerca DynaBeans ver

• Los BeanUtils Comunes Descripción de Paquetes y Javadocs.
• Struts FormDef

2.6 Cadenas Comunes

Una técnica popular para organizar el flujo de ejecución de procesamiento complejo es el patrón "Cadena de Responsabilidad", como se describe(entre muchos otros lugares) en el clásico libre de diseño de patrones "Gang of Four". El GoF resuma el patrón de la Cadena de Responsabilidad como "Evitar acoplamiento el remitente de una solicitud que ha recibido dando mas que un objeto a cambio para el manejo de la solicitud. La cadena recibe objetos y pasa la solicitud a lo largo de la cadena hasta que un objeto los maneje."

El patrón CoR nos ayuda a mantener componentes de software vagamente acoplado. Un componente puede llamar a una Cadena de Responsabilidad, sin conocer que objetos son en la cadena o como ellos son implementados. Lo mas importante, nosotros podemos ajustar la Cadena sin cambiar como los comunicantes invocan la Cadena. Como la versión 1.3, la Solicitud Procesador inicial, la cual actúa como el "kernel" de framework, es una Cadena de Responsabilidad.

Para implementar esta Cadena, la Solicitud Procesador usa el componente Cadena de Responsabilidad en los Apache Commons los cuales proveen una implementación estándar del patrón de CoR, a lo largo de varias implementaciones del Contexto y objetos de Comando usados por la Cadena al servicio a una solicitud.

Para mas acerca de Cadena de Responsabilidad, ver

• Cadenas de Responsabilidad ordinarias
• Una vista de Cadena Ordinaria
• Código mejor con Struts 1.3

Como de Struts 1.3 Cadenas ordinarias son usados para construir Solicitudes Procesadores iniciales para el framework.