Artculo

Inicio

Artculo

18
votar!

Lenguajes orientados a objeto

Java

J2EE

Catlogo de Patrones de Diseo J2EE. I.- Capa de

Presentacin

Front Controller
Contexto
Problema
Causas
Solucin
Estructura
Participantes y Responsabilidades
Estrategias
Consecuencias
Patrones Relacionados

Front Controller
Contexto
El mecanismo de manejo de peticiones de la capa de presentacin debe controlar y coordinar el
procesamiento de todos los usuarios a travs de varias peticiones. Dichos mecanismos de control
se pueden manejar de una forma centralizada o descentralizada.

Problema

El sistema requiere un punto de acceso centralizado para que el manejo de peticiones de la capa
de presentacin soporte la integracin de los servicios del sistema, recuperacin de contenidos,
control de vistas, y navegacin. Cuando el usuario accede a la vista directamente sin pasar un
mecanismo centralizado, podran ocurrir dos problemas:
Se requiere que cada vista proporcione sus propios servicios del sistema, lo que
normalmente resulta en duplicacin de cdigo.
La vista de navegacin se deja a los visores. Esto podra resultar en una mezcla de
contenidos y navegacin.
Adems, el control distribuido es ms difcil de mantener, ya que los cambios se tienen que
realizar en numerosos lugares.

Causas

El procesamiento de servicios del sistema comunes se completa por cada peticin. Por
ejemplo, el servicio de seguridad completa los chequeos de autentificacin y autorizacin.
La lgica se maneja mejor en una localizacin central en lugar de estar replicada dentro
de varias vistas.
Existen puntos de decisin con respecto a la recuperacin y manipulacin de los datos.
Se utilizan varias vistas para responder a peticiones de negocio similares.
Puede ser muy til un punto de contacto centralizado para manejar una peticin, por
ejemplo, para controlar y grabar el camino de un usuario por la site.
Los servicios del sistema y la lgica de control de vistas son relativamente sofisticados.

Solucin
Usar un controlador como el punto inicial de contacto para manejar las peticiones. El
controlador maneja el control de peticiones, incluyendo la invocacin de los servicios
de seguridad como la autentificacin y autorizacin, delegar el procesamiento de
negocio, controlar la eleccin de una vista apropiada, el manejo de errores, y el
control de la seleccin de estrategias de creacin de contenido.
El controlador proporciona un punto de entrada centralizado que controla y maneja las
peticiones Web. Centralizando los puntos de decisin y control, el controlador tambin ayuda a
reducir la cantidad de cdigo Java, llamadas a scriptles, embebidos en la pgina JavaServer
Pages (JSP).

Centralizar el control en el controlador y reduciendo la lgica de negocios en la vista permite

reutilizar el cdigo entre peticiones. Es una aproximacin preferible a la alternativa de embeber
cdigo en varias vistas porque esta aproximacin trata con entornos ms propensos a errores, y
de reutilizacin del tipo copiar-y-pegar.
Tpicamente, un controlador se coordina con un componente dispatcher. Los dispatchersson
responsable del control de la vista y de la navegacin. As, un dispatcher elige la siguiente vista
por el usuario y dirige el control al recurso. Los dispatchers podran encapsularse directametne
dentro del controlador o se puede extraer en un componente separado.
Aunque el patrn Front Controller sugiere la centralizacin del manejo de peticiones, no limita
el nmero de manejadores en el sistema, como lo hace Singleton. Una aplicacin podra utilizar
varios controladores en un sistema, cada uno mapeado a un conjunto de servicios distintos.
Estructura
La siguiente figura representa el diagrama de clases del patrn Front Controller.

Participantes y Responsabilidades
La siguiente figura representa el diagrama de la secuencia del patrn Front Controller. Muestra
como el controlador maneja una peticin:

Controller

El controlador es el punto de contacto inicial para manejar todas las peticiones en el sistema. El
controlador podra delegar a un helper para completar la autentificacin y la autorizacin de un
usuario o para iniciar la recuperacin de un contacto.
Dispatcher

Un dispatcher es el responsable del manejo de la vista y de la navegacin, controlando la

eleccin de la siguiente vista que se le presentar al usuario, y proporcionando el mecanismo

para dirigir el control a ese recurso.

Un dispatcher se puede encapsular dentro de un controlador o se puede separar en otro
componente que trabaja de forma coordinada. El dispatcher puede proporcionar un re-envo
esttico de la vista o un mecanismo de re-envo ms sofisticado.
El dispatcher utiliza un objeto RequestDispatcher (soportado en la especificacin Servlet) y
encapsula algn procesamiento adicional.
Helper

Un helper es el responsable de ayudar a la vista o al controlador a completar su procesamiento.

As, los helpers tienen muchas responsabilidades, incluyendo la recopilacin de los datos
requeridos por la vista y el almacenamiento en el modelo intermedio, en cuyo caso algunas veces
nos podemos referir al helper como un bean de valor. Adems, los helpers pueden adaptar este
modelo de datos para usarlo en la vista.
Una vista podra trabajar con cualquier nmero de helpers, que normalmente son componentes
JavaBeans (JSP 1.0+) y etiquetas personalizadas (JSP 1.1+). Adems, un helper podra
representar un objeto Command o un Transformador XSL, que se utiliza en combinacin con una
hoja de estilos para adaptar y convertir el modelo a la forma apropiada.
View

Una Vista representa y muestra informacin al cliente. La vista recupera informacin desde el
modelo. Los helpers soportan las diferentes vistas encapsulando y adaptanto el modelo de datos
subyacente para usarlo en el display.
Estrategias
Hay varias estrategias para implementar un controlador.
Servlet Front

La estrategia de Servlet Frontal sugiere la implementacin del controlador como un servlet.

Aunque semnticamente equivalente, es mejor que la Estrategia de JSP Frontal. El controlador
maneja los aspectos del manejo de peticiones que estn relacionados con el procesamiento de
negocio y el control de flujo. Estas responsabilidades estn relacionadas con, pero son
lgicamente independientes, del formateo de display, y es ms apropiado encapsularlas en un
servlet en lugar de en una pgina JSP.
Esta estrategia tiene algunos potenciales inconvenientes. En particular, no permite utilizar
algunas de las utilidadess del entorno de ejecucin JSP, como es el relleno automtico de
parmetros de la peticion. Afortunadamente, este inconveniente es mnimo porque es
relativamente fcil crear u obtener utilidades similares para su uso general. Abajo podemos ver un
ejemplo de la Estrategia Servlet Front:
public class EmployeeController extends HttpServlet {
// Initializes the servlet.
public void init(ServletConfig config) throws
ServletException {
super.init(config);
}
// Destroys the servlet.
public void destroy() {
}
/** Processes requests for both HTTP
* <code>GET</code> and <code>POST</code> methods.
* @param request servlet request
* @param response servlet response
*/
protected void processRequest(HttpServletRequest
request, HttpServletResponse response)
throws ServletException, java.io.IOException {
String page;
/**ApplicationResources provides a simple API
* for retrieving constants and other
* preconfigured values**/
ApplicationResources resource =
ApplicationResources.getInstance();
try {
// Use a helper object to gather parameter
// specific information.
RequestHelper helper = new
RequestHelper(request);
Command cmdHelper= helper.getCommand();

// Command helper perform custom operation

page = cmdHelper.execute(request, response);

}
catch (Exception e) {
LogManager.logMessage(
"EmployeeController:exception : " +
e.getMessage());
request.setAttribute(resource.getMessageAttr(),
"Exception occurred : " + e.getMessage());
page = resource.getErrorPage(e);
}
// dispatch control to view
dispatch(request, response, page);

/** Handles the HTTP <code>GET</code> method.

* @param request servlet request
* @param response servlet response
*/
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, java.io.IOException {
processRequest(request, response);
}
/** Handles the HTTP <code>POST</code> method.
* @param request servlet request
* @param response servlet response
*/
protected void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, java.io.IOException {
processRequest(request, response);
}
/** Returns a short description of the servlet */
public String getServletInfo() {
return "Front Controller Pattern" +
" Servlet Front Strategy Example";
}

protected void dispatch(HttpServletRequest request,

HttpServletResponse response,
String page)
throws javax.servlet.ServletException,
java.io.IOException {
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(page);
dispatcher.forward(request, response);
}

JSP Front

La estrategia de JSP Frontal sugiere la implementacin del controlador como una pgina JSP.
Aunque semnticamente equivalente, es mejor utilizar la Estrategia de Servlet Frontal. Como el
controlador maneja el procesamiento que no est especificamente relacionado con el formateo
de la salida, no tiene sentido implementar este componente como una pgina JSP.
La implementacin del controlador como una pgina JSP tiene otra razn para no ser la
preferida: Requiere que un desarrollador de software trabaje con una pgina de etiquetas para
poder modificar la lgica del control de peticiones. El siguiente listado es un ejemplo de esta
estrategia:
<%@page contentType="text/html"%>
<%@ page import="corepatterns.util.*" %>
<html>
<head><title>JSP Front Controller</title></head>
<body>
<h3><center> Employee Profile </h3>

<%
/**Control logic goes here...
At some point in this code block we retrieve
employee information, encapsulate it within a value
object and place this bean in request scope with the
key "employee". This code has been omitted.
We either dispatch to another JSP at this point or
simply allow the remaining portions of scriptlet
code to execute**/
%>
<jsp:useBean id="employee" scope="request"
class="corepatterns.util.EmployeeTO"/>
<FORM method=POST >
<table width="60%">
<tr>
<td> First Name : </td>
<td> <input type="text"
name="<%=Constants.FLD_FIRSTNAME%>"
value="<jsp:getProperty name="employee"
property="firstName"/>"> </td>
</tr>
<tr>
<td> Last Name : </td>
<td>
<input type="text"
name="<%=Constants.FLD_LASTNAME%>"
value="<jsp:getProperty name="employee"
property="lastName"/>"></td>
</tr>
<tr>
<td> Employee ID : </td>
<td>
<input type="text"
name="<%=Constants.FLD_EMPID%>"
value="<jsp:getProperty name="employee"
property="id"/>"> </td>
</tr>
<tr>
<td>
<input type="submit"
name="employee_profile"> </td>
<td> </td>
</tr>
</table>
</FORM>
</body>
</html>
Command and Controller

Basada en el patrn Commando de [GoF], la estrategia de Commando y Controlador sugiere

proporcionar un interface genrico para los componentes helper en los que el controlador podra
delegar responsabilidades, minimizando el acoplamiento entre estos componentes. Aadir o
modificar el trabajo que necesitan realizar estos helpers no requiere ningn cambio en el interface
entre el controlador y ellos, sino en el tipo y/o contenido de los comandos. Esto proporciona un
mecanismo flexible y fcilmente extensible para que los desarrolladores puedan aadir
comportamientos al manejo de peticiones.
Finalmente, como el procesamiento de comandos no est acoplado a la invocacin de
comandos, el mecanismo de procesamiento de comandos se podra reutilizar para varios tipos de
clientes, no slo con los navegadores Web. Esta estrategia tambin facilita la creacin de
comandos compuestos. Aqu tenemos un ejemplo de esta estrategia:
/** This processRequest method is invoked from both
* the servlet doGet and doPost methods **/
protected void processRequest(HttpServletRequest
request, HttpServletResponse response)
throws ServletException, java.io.IOException {
String resultPage;
try {

RequestHelper helper = new RequestHelper(request);

/** the getCommand() method internally uses a
factory to retrieve command objects as follows:
Command command = CommandFactory.create(
request.getParameter("op"));
**/
Command command = helper.getCommand();
// delegate request to a command object helper
resultPage = command.execute(request, response);

}
catch (Exception e) {
LogManager.logMessage("EmployeeController",
e.getMessage() );
resultPage = ApplicationResources.getInstance().
getErrorPage(e);
}
}

dispatch(request, response, resultPage);

En la siguiente figura podemos ver el diagrama de secuencia de la estrategia Command and

Controller.

Phisical Resource Mappping

En la estrategia de Mapeo Fsico de Recursos todas las peticiones se hacen sobre nombres de
recursos fsicos especificos en lugar de sobre nombres lgicos. Un ejemplo es la siguiente
URL:http://some.server.com/resource1.jsp. En el caso de un controlador, un ejemplo de
URL podra ser: http://some.server.com/servlet/Controller. Es preferible utilizar la
estrategia de Mapeo Lgico de Recursos porque proporciona una mayor flexibilidad, porque nos
permite mapear los recuros de una forma declarativa.
Logical Resource Mapping

En la estrategia de Mapeo de Recurso Lgico todas las peticiones se hacen sobre nombres de
recursos lgicos en vez de sobre nombres fsicos especficos. Los recursos fsicos a los que se
refieren estos nombres lgicos podran modificarse de una forma declarativa.
Por ejemplo, la URL http://some.server.com/process podra mapearse como:
process=resource1.jsp
o como:
process=resource2.jsp
o como:
process=servletController
Multiplexed Resource Mapping

La estrategia de Mapeo Multiplexado de Recursos realmente es una estrategia de Mapeo

Lgico de Recursos. Esta estrategia no mapea slo a un nombre lgico, sino a un conjunto
completo de nombres lgicos, para un slo recurso fsico. Por ejemplo, un mapeo de comodn
podra mapear todas las peticiones que terminen en .ctrl a un controlador especfico, como
podermos ver en la siguiente tabla:

Peticin>

Mapeo

http://some.server.com/action.ctrl *.ctrl = servletController

De hecho, es la estragegia que utilizan los motores de pginas JSP para asegurarse de que las
peticiones de recursos de pginas JSP (es decir, recursos cuyos nombres terminan en .jsp) las
procesa el manejador apropiado.
Se pueden aadir informacin adicional a una peticion, proporcionando mayores detalles para
este mapeo lgico, como se puede ver en la siguiente tabla:

Peticin>
http://some.server.com/profile.ctrl?usecase=
create

Mapeo
*.ctrl =
servletController

Un beneficio importante de la utilizacin de esta estrategia es que proporciona una enorme

flexibilidad cuando diseanos nuestros componentes de manejo de peticiones. Cuando se
combina con las otras estrategias, como con la estrategia Command and Controller, se pueden
crear un potente marco de trabajo para manejar peticiones.
Consideremos un controlador que maneja todas las peticiones que terminan en .ctrl, como
hemos visto antes. Consideremos tambin la parte izquierda del nombre de recursos delimitado
por puntos (profile en el ejemplo de arriba) para que sea una parte del nombre de un ejemplo.
Ahora combinamos este nombre con el valor de parmetro de la consulta (creado en el ejemplo
de arriba). Estamos diciendo a nuestos manejador de peticiones que queremos procesar un
ejemplo llamado crear perfil. Nuestro mapeo de recursos multiplexado enva la peticin a
nuestroservletController, que es parte del mapeo mostrado en la tabla anterior. Nuestro
controlador crea el objeto command apropiado, segn describimos en la Estrategia Command and
Controller. Cmo sabe el controlador en qu objeto command debera delegar? Utilizando la
informacin adicional de la URI de la peticin, el controlador delega en el objeto command que
maneja la creacin de perfiles. Est podra ser un objeto ProfileCommand que sirve peticiones
para la creacin y modificacin de perfiles, o podra ser un objeto ms especfico
comoProfileCreationCommand.
Dispatcher in Controller

Cuando la funcionalidad del dispatcher es mnima, se puede plegar junto al controlador, como se
muestra en la siguiente figura:

Base Front

La estrategia Base Front utilizada en combinacin con la estrategia Servlet Front, sugiere la
implementacin de una clase base controladora, cuya implementacin deben extender otros
controladoes. La clase Base Front podra contener implementaciones comunes y por defecto,
aunque las subclases puedan sobreescribir estas implementaciones. El inconviente de esta
estrategia es el hecho de que un superclase compartida, aunque promueve la reutilizacin y la

comparticin, tiene el problema de crear un herencia frgil, donde los cambios necesarios para
una subclase afectan a todas las dems subclases.
Filter Controller

Los filtros proporcionan un soporte similar para la centralizacin de manejo de peticiones. As,
algunos aspectos de un controlador se pueden implementar de forma razonable como un filtro.
Al mismo tiempo, los filtros se enfocan principalmente en la intercepcin y decoracin de
peticiones, no en el procesamiento y en la generacin de respuestas. Aunque hay un
solapamietno de responsabilidades, como en el manejo del log y la depuracin, cada
componente complementa a los otros cuando se utilizan de la forma apropiada.

Consecuencias

Centraliza el Control
Un controlador proporciona un lugar central para manejar los servicios del sistema y la
lgica de negocios entre varias peticiones. Un controlador maneja el procesamiento de la
lgica de negocio y el manejo de peticiones. El acceso centralizado a una aplicacin
significa que las peticiones se pueden seguir y guardar muy fcilmente. Debemos tener en
mente, que como controles centralizados, es posible presentar un slo punto de fallo. En
la prctica, esto rramente es un problema, ya que tpicamente existe mltiples
controladores, bien dentro de un slo servidor o en un cluster.
Mejora la Manejabilidad de la Seguridad
Un controlador centraliza el control, propocionando un punto de choque para intentos de
accesos ilcitos en la aplicacin Web. Adems, auditar una sola entrada en la aplicacin
requiere menos recursos que distribuir los chequeos de seguridad entre todas las pginas.
Mejora la Reutilizabilidad
Un controlador promueve el particionamiento limpio de la aplicacin y aconseja la
reutilizacin, ya que el cdigo que es comn entre los componentes se mueve dentro de
un controlador o es manejado por un controlador.

Patrones Relacionados
View Helper
El patrn Front Controller, en conjuncin con el patrn View Helper, describe la
creacin de lgica de negocio de la vista y proporciona un punto central de control y
reenvio. El flujo lgico se construye dentro del controlador y el cdigo de manejo de
datos se mueve hacia los helpers.
Intercepting Filter
Tanto Intercepting Filter como Front Controller describen formas de centralizar el
control de ciertos tipos de procesamiento de peticiones, sugiriendo diferentes
aproximaciones a este problema.
Dispatcher View y Service to Worker
Los patrones Dispatcher View y Service to Worker son otras forma de nombrar la
combinacin entre el patrn View Helper con un dispatcher, y un patrn Front
Controller. Dispatcher View y Service to Worker, aunque estructuralmente son
iguales, describen diferentes divisiones de labores entre los componentes.

Publicado por:
Ricard Lou Torrijos