Muchos documentos de requerimientos usados para construir aplicaciones Web se enfocan en la Vista. Sin embargo, deber�amos asegurarnos que tambi�n est� claramente definido el procesamiento requerido por cada solicitud enviada desde la perspectiva del Modelo. En general, el desarrollador de componentes del Modelo se enfocar� en la creaci�n de clases JavaBeans que soporten todos los requerimientos de funcionalidad. La natural precisi�n de los beans requeridos por una aplicaci�n particular variar� mucho dependiendo de esos requerimientos, pero generalmente pueden clasificarse en varias categor�as descritas abajo. Sin embargo, primero es �til una breve revisi�n del concepto de "�mbito" en relaci�n con los beans y JSP.
�Los JavaBeans y el �mbito
Dentro de una aplicaci�n basada en web, los Javabeans pueden almacenarse en (y ser accedidos desde) varias colecciones de "atributos" diferentes. Cada colecci�n tiene diferentes reglas para el tiempo de vida de esa colecci�n, y la visibilidad de los Beans almacenados en ella. Juntos, las reglas que definen el tiempo de vida y la visiblidad se llama el �mbito de esos beans. La especificaci�n JavaServer Pages (JSP) define las elecciones de �mbito usando los siguientes t�rminos (con el concepto del API Servlet equivalente entre par�ntesis):
- page - Beans que son visibles dentro de una s�la p�gina JSP, para el tiempo de vida de la solicitud actual (Variables locales del m�todo service() )
- request - Beans que son visibles dentro de una s�la p�gina JSP, as� como EN cualquier p�gina o servlet que est� incluido en esta p�gina, o reenviado por esta p�gina. (Atributos Request).
- session - Beans que son visibles para todas las p�ginas JSP y los servlets que participan en una sesi�n de usuario particular, a trav�s de una o m�s solicitudes. (Atributos Session).
- application - Beans que son visibles para todas las p�ginas JSP y los servlets que forman parte de una aplicaci�n Web. (Atributos de contexto Servlet).
Es importante recordar que las p�ginas JSP y los servlets, al igual que las aplicaciones Web comparten los mismos conjuntos de colecciones de beans. Por ejemplo, un Bean almacenado como un atributo request en un servlet como este:
MyCart mycart = new MyCart(...);
request.setAttribute("cart", mycart);
es inmediatamente visible a una p�gina JSP a la que se reenv�e este servlet, usando una etiqueta de acci�n est�ndard como esta:
<jsp:useBean id="cart" scope="request" class="com.mycompany.MyApp.MyCart"/>
�Beans ActionForm
Nota: los beans ActionForm est�n realmente m�s cercanos a la Vista que al Modelo.
El marco de trabajo Struts generalmente asume que hemos definido un bean ActionForm (es decir, una clase Java que extiende la clase ActionForm) por cada formulario de entrada necesario en nuEstra aplicaci�n. Los beans ActionForm algunas veces son s�lo llamados "beans formuLario". Si declaramos dichos beans en nuestro fichero de configuraci�n ActionMapping (ver "Construir los Componentes del Controlador"), el servlet controlador Struts realiza autom�ticamente los siguientes servicios por nosotros, antes de llamar al m�todo Action apropiado:
- Chequea en la sesi�n de usuario si hay un ejemplar de un bean de la clase apropiada, bajo la clave apropiada.
- Si no est� disponible dicho bean en el �mbio de la sesi�n, se crea uno nuevo autom�ticamente y se a�ade a la sesi�n de usuario.
- Por cada par�metro de la solicitud cuyo nombre corresponda con el nombre de una propiedad del bean, se llamar� al correspondiente m�todo set(). Esto opera de una forma similar a la acci�n JSP est�ndard <jsp:setProperty> cuando usamos el comod�n asterisco para seleccionar todas las propiedades.
- El bean ActionForm actualizado ser� pasado al m�todo perform() de la clase Action cuando es llamado, haciendo que esos valores est�n disponibles inmediatamente.
Cuando codifiquemos nuestros beans ActionForm, debemos tener en mente los siguientes principios:
- La propia clase ActionForm no requiere que se implemente ning�n m�todo espec�fico. Se usa para identificar el rol que esos beans particulares juegan en la arquitectura general. Normalmente, un bean ActionForm s�lo tendr� metodos setxxx() y getxxx(), sin l�gica de negocio.
- El objeto ActionForm tambi�n ofrece un mecanismo de validaci�n est�ndard. Si sobreescribimos un m�todo "stub", y proporcionamos mensajes de error en el recurso de aplicaci�n est�ndard, Struts validar� autom�ticamente la entrada del formualrio (usando nuestro m�todo). Ver Validaci�n del Formulario para m�s detalles. Por supuesto, tambi�n podemos ignorar la validaci�n de ActionForm y proporcionar nuestro propio objeto Action.
- Definir una propiedad (asociada con m�todos getXxx() y setXxx()) para cada campo que est� presente en el formulario. El nombre del campo y el nombre de la propiedad deben corresponder de acuerdo a las convenciones usuales de los JavaBeans. Por ejemplo, un campo de entrada llamado username har� que se llame al m�todo setUsername().
- Debemos pensar en nuestros beans ActionForm como firewall ente HTTP y el objeto Action. Usamos el m�todo validate para asegurarnos de que est�n presentes todas las propiedades requeridas, y que contienen valores razonables. Un ActionForm que falla en la validaci�n incluso ni ser� presentado para el manejo del Action.
- Tambi�n podr�amos situar un ejemplar bean en nuestro formulario, y usar referencias a propieades anidadas. Por ejemplo, podr�amos tener un bean "customer" en nuestro Action Form, y luego referirnos a la propiedad "customer.name" en nuestra vista JSP. Esto corresponder�a con los m�todos customer.getName() y customer.setName(string Name) de nuestro bean customer.
- Cuidado: si anidamos ejemplares de beans existentes en nuestro formulario, debemos pensar en las propiedades que exponemos. Cualquier propiedad p�blica en un ActionForm que acepta un simple valor String puede seleccionarse con un string de consulta. Podr�a ser muy �til situar dichos beans dentro de una fina "envoltura" que exponga s�lo las propiedades requeridas. Esta envoltura tambi�n puede proporcionar un filtro para asegurarnos en tiempo de ejecuci�n de que las propiedades no se seleccionan con valores inapropiados.
Deber�as haber observado que un "formulario", en el sentido discutido aqu�, no corresponde necesariamente con una s�la p�gina JSP en el interface de usuario. Es com�n en muchas aplicaciones tener un "formulario" (desde la perspectiva del usuario) que se extienda sobre m�ltiples p�ginas. Piensa por ejemplo, en un interface de usuario al estilo de los wizard que se utilizan comunmente cuando instalamos nuevas aplicaciones. Struts nos aconseja definir un s�lo ActionForm que contenga las propiedades de todos los campos, sin importar que p�gina de campo se est� mostrando actualmente. De igual forma, las distintas p�ginas del mismo formulario deber�an ser reenvidas a la misma clase Action. Si seguimos estas sugerencias, los dise�adores de p�ginas podr�n reordenar los campos entre varias p�ginas, frecuentemente sin requerir que cambiemos la l�gica de procesamiento.
�Beans de Estado del Sistema
El estado real de un sistema normalmente est� representado por un conjunto de una o mas clases JavaBeans, cuyas propiedades definen el estado actual. Un sistema de tarjeta de compra, por ejemplo, incluir� un bean que represente la tarjeta que est� siendo mantenida por cada comprador individual, e incluir� (entre otras cosas) un conjunto de �tems que el comprador ha seleccionado. Separadamente, el sistema tambi�n incluir� diferentes beans para la informaci�n del perfil del usuario (incluyendo su tarjeta de cr�dito y su direcci�n de env�o), as� como el catalogo de �tems disponibles y sus niveles de inventario actuales.
Para sistemas de peque�a escala, o para informaci�n de estado que no necesita guardarse durante mucho tiempo, un conjunto de beans de estado del sistema podr�a contener todos los conocimientos que el sistema tiene sobre esos detalles particulares. O, como es el caso m�s frecuente, los beans de estado del sistema representar�n informaci�n que est� almacenada permanentemente en alguna base de datos externa (como un objeto CustomerBean que responde a una fila de la tabla CUSTOMERS), y son creados o eliminados de la memoria del servidor cuando se necesita. Los JavaBeans Enterprise de Entidad tambi�n se usan para esto en aplicaciones de gran escala.
�Beans de L�gica de Negocio
Deber�amos encapsular la l�gica funcional de nuestra aplicaci�n como llamadas a m�todos en JavaBeans dise�ados para este prop�sito. Estos m�todos pueden ser parte de las mismas clases usadas para los beans de estado del sistema, o podr�an estar en clases separadas dedicadas a realizar la l�gica. En el �ltimo caso, normalmente necesitaremos pasarle los beans de estado del sistema para que sean manipulados por estos m�todos como argumentos.
Para una reutilizaci�n m�xima del c�digo, los beans de la l�gica del negocio deber�an ser dise�ados e implementados para que no sepan que est�n siendo ejecutados en un entorno de aplicaci�n Web. Si nos encontramos que tenemos que importar una clase javax.servlet.* en nuestro bean, estamos ligando �sta l�gica de negocio al entorno de una aplicaci�n Web. Debemos considerar reordenar las cosas para que nuestras clases Action (parte del rol del Controlador, seg�n se describe abajo) traduzcan toda la informaci�n requerida desde la solicitud HTTP que est� siendo procesada en llamadas a m�todos setXxx() de propiedades de nuestros beans de l�gica de negocio, despu�s de que se pueda hacer una llamada a un m�todo execute(). Dicha clase de l�gica de negocio podr�a reutilizarse en entornos distintos al de la aplicaci�n Web para el que fue construida en un principio.
Dependieno de la complejidad y del �mbito de nuestra aplicaci�n, los beans de l�gica de negocio podr�an ser JavaBeans ordinarios que interact�an con beans de estado del sistema que son pasados como argumentos, o JavaBeans ordinarios que aceden a una base de datos usando llamadas JDBC. Para grandes aplicaciones, estos beans frecuentemente ofrecer�n JavaBeans Enterprise (EJBs) con o sin estado en su lugar.
�Acceder a Bases de Datos Relacionales
Struts puede definir las fuentes de datos para una aplicaci�n desde dentro de un fichero de configuraci�n est�ndard. Tambi�n se proporciona un simple almacen de conexiones JDBC.
Despu�s de definir la fuente de datos, aqu� tenemos un ejemplo de c�mo establecer una conexi�n desde dentro del m�todo perform de la clase Action:
public ActionForward
perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
{
try {
javax.sql.DataSource dataSource =
servlet.findDataSource(null);
java.sql.Connection myConnection =
dataSource.getConnection();
//do what you wish with myConnection
} catch (SQLException sqle) {
getServlet().log("Connection.process", sqle);
} finally {
//enclose this in a finally block to make
//sure the connection is closed
try {
myConnection.close();
} catch (SQLException e) {
getServlet().log("Connection.close", e);
}
}
}
Observa que el almacen de conexiones Struts gen�rico es un componente opcional. Muchas aplicaciones Struts usan otros almacenes de conexiones para un mejor rendimiento, especialmente con sistemas de producci�n de alto volumen.