Front Controler

7/23/2019 Front Controler

1/8

Artculonicio Artculo Lenguajes orientados a objeto Java J2EE

18votar!

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

Front Controller

Contexto

Problema

Causas

Solucin

Estructura

Participantes y Responsabilidades

Estrategias

Consecuencias

Patrones Relacionados

Front ControllerContexto

mecanismo de manejo de peticiones de la capa de presentacin debe controlar y coordinar elrocesamiento de todos los usuarios a travs de varias peticiones. Dichos mecanismos de controle pueden manejar de una forma centralizada o descentralizada.

Problema

sistema requiere un punto de acceso centralizado para que el manejo de peticiones de la capae presentacin soporte la integracin de los servicios del sistema, recuperacin de contenidos,

ontrol de vistas, y navegacin. Cuando el usuario accede a la vista directamente sin pasar unecanismo centralizado, podran ocurrir dos problemas:

Se requiere que cada vista proporcione sus propios servicios del sistema, lo quenormalmente resulta en duplicacin de cdigo.La vista de navegacin se deja a los visores. Esto podra resultar en una mezcla decontenidos y navegacin.

dems, el control distribuido es ms difcil de mantener, ya que los cambios se tienen queealizar en numerosos lugares.

Causas

El procesamiento de servicios del sistema comunes se completa por cada peticin. Porejemplo, el servicio de seguridad completalos chequeos de autentificacin y autorizacin.La lgica se maneja mejor en una localizacin central en lugar de estar replicada dentrode 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, porejemplo, 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

sar un controlador como el punto inicial de contacto para manejar las peticiones. Elontrolador maneja el control de peticiones, incluyendo la invocacin de los serviciose seguridad como la autentificacin y autorizacin, delegar el procesamiento deegocio, controlar la eleccin de una vista apropiada, el manejo de errores, y elontrol de la seleccin de estrategias de creacin de contenido.

controlador proporciona un punto de entrada centralizado que controla y maneja las

eticiones Web. Centralizando los puntos de decisin y control, el controlador tambin ayuda aeducir la cantidad de cdigo Java, llamadas a scriptles, embebidos en la pgina JavaServerages (JSP).
http://programacion.net/articuloshttp://programacion.net/articulo/poohttp://programacion.net/articulo/javahttp://programacion.net/articulo/j2eehttp://programacion.net/articulo/j2eehttp://programacion.net/articulo/javahttp://programacion.net/articulo/poohttp://programacion.net/articuloshttp://programacion.net/


2/8

entralizar el control en el controlador y reduciendo la lgica de negocios en la vista permiteeutilizar el cdigo entre peticiones. Es una aproximacin preferible a la alternativa de embeberdigo en varias vistas porque esta aproximacin trata con entornos ms propensos a errores, ye reutilizacin del tipo copiar-y-pegar.picamente, un controlador se coordina con un componente dispatcher. Los dispatcherssonesponsable del control de la vista y de la navegacin. As, un dispatcherelige la siguiente vistaor el usuario y dirige el control al recurso. Los dispatcherspodran encapsularse directametneentro del controlador o se puede extraer en un componente separado.unque el patrn Front Controllersugiere la centralizacin del manejo de peticiones, no limitanmero de manejadores en el sistema, como lo hace Singleton. Una aplicacin podra utilizar

arios controladores en un sistema, cada uno mapeado a un conjunto de servicios distintos.Estructura

a siguiente figura representa el diagrama de clases del patrn Front Controller.

Participantes y Responsabilidades

a siguiente figura representa el diagrama de la secuencia del patrn Front Controller. Muestraomo el controlador maneja una peticin:

Controller

controlador es el punto de contacto inicial para manejar todas las peticiones en el sistema. Elontrolador podra delegar a un helperpara completar la autentificacin y la autorizacin de unsuario o para iniciar la recuperacin de un contacto.

Dispatcher

n dispatcher es el responsable del manejo de la vista y de la navegacin, controlando laeccin de la siguiente vista que se le presentar al usuario, y proporcionando el mecanismo


3/8

ara dirigir el control a ese recurso.n dispatcher se puede encapsular dentro de un controlador o se puede separar en otroomponente que trabaja de forma coordinada. El dispatcher puede proporcionar un re-envosttico de la vista o un mecanismo de re-envo ms sofisticado.dispatcherutiliza un objeto RequestDispatcher (soportado en la especificacin Servlet) y

ncapsula algn procesamiento adicional.Helper

n helperes el responsable de ayudar a la vista o al controlador a completar su procesamiento.s, los helpers tienen muchas responsabilidades, incluyendo la recopilacin de los datosequeridos por la vista y el almacenamiento en el modelo intermedio, en cuyo caso algunas vecesos podemos referir al helpercomo un bean de valor. Adems, los helperspueden adaptar esteodelo de datos para usarlo en la vista.

na vista podra trabajar con cualquier nmero de helpers, que normalmente son componentesavaBeans (JSP 1.0+) y etiquetas personalizadas (JSP 1.1+). Adems, un helper podraepresentar un objeto Commando un Transformador XSL, que se utiliza en combinacin con unaoja de estilos para adaptar y convertir el modelo a la forma apropiada.

View

na Vista representa y muestra informacin al cliente. La vista recupera informacin desde elodelo. Los helperssoportan las diferentes vistas encapsulando y adaptanto el modelo de datos

ubyacente para usarlo en el display.Estrategias

ay varias estrategias para implementar un controlador.Servlet Front

a estrategia de Servlet Frontal sugiere la implementacin del controlador como un servlet.unque semnticamente equivalente, es mejor que la Estrategia de JSP Frontal. El controlador

aneja los aspectos del manejo de peticiones que estn relacionados con el procesamiento deegocio y el control de flujo. Estas responsabilidades estn relacionadas con, pero songicamente independientes, del formateo de display, y es ms apropiado encapsularlas en un

ervlet en lugar de en una pgina JSP.sta estrategia tiene algunos potenciales inconvenientes. En particular, no permite utilizargunas de las utilidadess del entorno de ejecucin JSP, como es el relleno automtico dearmetros de la peticion. Afortunadamente, este inconveniente es mnimo porque eselativamente fcil crear u obtener utilidades similares para su uso general. Abajo podemos ver unemplo de la Estrategia Servlet Front:ublic 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

* GET and POST methods.* @param request servlet request

* @param response servlet response*/

protected void processRequest(HttpServletRequestrequest, 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();


4/8

// 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 viewdispatch(request, response, page);

}

/** Handles the HTTP GET 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 POST 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

a estrategia de JSP Frontalsugiere la implementacin del controlador como una pgina JSP.unque semnticamente equivalente, es mejor utilizar la Estrategia de Servlet Frontal. Como elontrolador maneja el procesamiento que no est especificamente relacionado con el formateoe la salida, no tiene sentido implementar este componente como una pgina JSP.a implementacin del controlador como una pgina JSP tiene otra razn para no ser lareferida: Requiere que un desarrollador de software trabaje con una pgina de etiquetas paraoder modificar la lgica del control de peticiones. El siguiente listado es un ejemplo de estastrategia:%@page contentType="text/html"%>

%@ page import="corepatterns.util.*" %>html>

head>JSP Front Controller

body>

h3> Employee Profile


5/8

%

**Control logic goes here...

At some point in this code block we retrieveemployee information, encapsulate it within a value

object and place this bean in request scope with thekey "employee". This code has been omitted.

We either dispatch to another JSP at this point or

simply allow the remaining portions of scriptletcode to execute**/

>FORM method=POST >

table width="60%">tr>

First Name :

td>

/tr>tr>

Last Name :

/tr>

tr>

Employee ID : /tr>

tr>

/tr>/table>

/FORM>

/body>

/html>

Command and Controller

asada en el patrn Commandode [GoF], la estrategia de Commando y Controladorsugiereroporcionar un interface genrico para los componentes helperen los que el controlador podraelegar responsabilidades, minimizando el acoplamiento entre estos componentes. Aadir oodificar el trabajo que necesitan realizar estos helpersno requiere ningn cambio en el interfacentre el controlador y ellos, sino en el tipo y/o contenido de los comandos. Esto proporciona unecanismo flexible y fcilmente extensible para que los desarrolladores puedan aadir

omportamientos al manejo de peticiones.nalmente, como el procesamiento de comandos no est acoplado a la invocacin deomandos, el mecanismo de procesamiento de comandos se podra reutilizar para varios tipos deientes, no slo con los navegadores Web. Esta estrategia tambin facilita la creacin deomandos compuestos. Aqu tenemos un ejemplo de esta estrategia:

** This processRequest method is invoked from both* the servlet doGet and doPost methods **/

rotected void processRequest(HttpServletRequestrequest, HttpServletResponse response)

throws ServletException, java.io.IOException {

String resultPage;try {


6/8

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 helperresultPage = command.execute(request, response);

}catch (Exception e) {

LogManager.logMessage("EmployeeController",e.getMessage() );

resultPage = ApplicationResources.getInstance().getErrorPage(e);

}

dispatch(request, response, resultPage);

n la siguiente figura podemos ver el diagrama de secuencia de la estrategia Command andontroller.

Phisical Resource Mappping

n la estrategia de Mapeo Fsico de Recursostodas las peticiones se hacen sobre nombres deecursos fsicos especificos en lugar de sobre nombres lgicos. Un ejemplo es la siguiente

RL:http://some.server.com/resource1.jsp. En el caso de un controlador, un ejemplo deRL podra ser: http://some.server.com/servlet/Controller. Es preferible utilizar lastrategia de Mapeo Lgico de Recursos porque proporciona una mayor flexibilidad, porque nosermite mapear los recuros de una forma declarativa.

Logical Resource Mapping

n la estrategia de Mapeo de Recurso Lgicotodas las peticiones se hacen sobre nombres deecursos lgicos en vez de sobre nombres fsicos especficos. Los recursos fsicos a los que seefieren estos nombres lgicos podran modificarse de una forma declarativa.or ejemplo, la URL http://some.server.com/processpodra mapearse como:rocess=resource1.jsp

como:rocess=resource2.jsp

como:

rocess=servletControllerMultiplexed Resource Mapping


7/8

a estrategia de Mapeo Multiplexado de Recursos realmente es una estrategia de Mapeogico de Recursos. Esta estrategia no mapea slo a un nombre lgico, sino a un conjuntoompleto de nombres lgicos, para un slo recurso fsico. Por ejemplo, un mapeo de comodnodra mapear todas las peticiones que terminen en .ctrl a un controlador especfico, comoodermos ver en la siguiente tabla:

Peticin> Mapeottp://some.server.com/action.ctrl *.ctrl = servletController

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

Peticin> Mapeottp://some.server.com/profile.ctrl?usecase=reate

*.ctrl =servletController

n beneficio importante de la utilizacin de esta estrategia es que proporciona una enormeexibilidad cuando diseanos nuestros componentes de manejo de peticiones. Cuando seombina con las otras estrategias, como con la estrategia Command and Controller, se puedenear un potente marco de trabajo para manejar peticiones.onsideremos un controlador que maneja todas las peticiones que terminan en .ctrl, comoemos visto antes. Consideremos tambin la parte izquierda del nombre de recursos delimitadoor puntos (profile en el ejemplo de arriba) para que sea una parte del nombre de un ejemplo.hora combinamos este nombre con el valor de parmetro de la consulta (creado en el ejemploe arriba). Estamos diciendo a nuestos manejador de peticiones que queremos procesar un

emplo llamado crear perfil. Nuestro mapeo de recursos multiplexado enva la peticin auestroservletController, que es parte del mapeo mostrado en la tabla anterior. Nuestroontrolador crea el objeto commandapropiado, segn describimos en la Estrategia Command andontroller. Cmo sabe el controlador en qu objeto command debera delegar? Utilizando laformacin adicional de la URI de la peticin, el controlador delega en el objeto commandqueaneja la creacin de perfiles. Est podra ser un objeto ProfileCommand que sirve peticionesara la creacin y modificacin de perfiles, o podra ser un objeto ms especficoomoProfileCreationCommand.

Dispatcher in Controller

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

Base Front

a estrategia Base Front utilizada en combinacin con la estrategia Servlet Front, sugiere lamplementacin de una clase base controladora, cuya implementacin deben extender otros

ontroladoes. La clase Base Front podra contener implementaciones comunes y por defecto,unque las subclases puedan sobreescribir estas implementaciones. El inconviente de estastrategia es el hecho de que un superclase compartida, aunque promueve la reutilizacin y la


8/8

omparticin, tiene el problema de crear un herencia frgil, donde los cambios necesarios parana subclase afectan a todas las dems subclases.

Filter Controller

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

Consecuencias

Centraliza el ControlUn 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 lalgica de negocio y el manejo de peticiones. El acceso centralizado a una aplicacinsignifica que las peticiones se pueden seguir y guardar muy fcilmente. Debemos tener enmente, que como controles centralizados, es posible presentar un slo punto de fallo. Enla prctica, esto rramente es un problema, ya que tpicamente existe mltiplescontroladores, bien dentro de un slo servidor o en un cluster.Mejora la Manejabilidad de la SeguridadUn controlador centraliza el control, propocionando un punto de choque para intentos deaccesos ilcitos en la aplicacin Web. Adems, auditar una sola entrada en la aplicacinrequiere menos recursos que distribuir los chequeos de seguridad entre todas las pginas.Mejora la ReutilizabilidadUn controlador promueve el particionamiento limpio de la aplicacin y aconseja lareutilizacin, 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 HelperEl patrn Front Controller, en conjuncin con el patrn View Helper, describe lacreacin de lgica de negocio de la vista y proporciona un punto central de control yreenvio. El flujo lgico se construye dentro del controlador y el cdigo de manejo dedatos se mueve hacia los helpers.Intercepting FilterTanto Intercepting Filter como Front Controller describen formas de centralizar elcontrol de ciertos tipos de procesamiento de peticiones, sugiriendo diferentesaproximaciones a este problema.Dispatcher Viewy Service to WorkerLos 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 FrontController. Dispatcher View y Service to Worker, aunque estructuralmente soniguales, describen diferentes divisiones de labores entre los componentes.

Publicado por:Ricard Lou Torrijos

Front Controler

Documents

Transcript of Front Controler