Desarrollo de Aplicaciones

Web con Java aplicando el patrón

de diseño MVC Sin Utilizar un Fra-
mework
Francisco Jacob Ávila Camacho*
Adolfo Meléndez Ramírez*
Valentín Roldán Vázquez**

Resumen

E n este trabajo presentamos la forma en que se puede implementar el

patrón de diseño MVC (Modelo Vista Controlador) de una manera sencilla,
sin necesidad de incorporar un framework como struts o spring, lo cual se
vuelve conveniente cuando se requiere desarrollar una aplicación en poco
tiempo y no se tienen los conocimientos de un framework que implemente
MVC.
El trabajo describe las características del patrón de diseño MVC y la
6 conveniencia de utilizarlo aún en aplicaciones sencillas para generar una
solución basada en estándares y en las mejores prácticas del desarrollo de
25

software. El artículo no pretende ser un tutorial, sino más bien una justificación
y una guía respecto a la conveniencia de utilizar MVC en el desarrollo de
aplicaciones Web. La arquitectura del programa utilizado como ejemplo,
pretende servir de base para una aplicación web más elaborada o compleja.
Keywords: Aplicaciones Web, Java, Mejores prácticas, Modelo Vista
Acerca de los autores... Controlador MVC, Patrón de Diseño, JSP, Servlets.
*
Profesor en la División de Ingeniería en Sistemas
Computacionales, Tecnológico de Estudios Superiores
de Ecatepec
Keywords: Aplicaciones Web, Java, Mejores prácticas, Modelo Vista
** Profesor en el Departamento de Matemáticas, UNAM Controlador MVC, Patrón de Diseño, JSP, Servlets.
FES Cuautitlán
 Introducción

L a plataforma Java Enterprise Edition (JEE) fue concebida para construir

presencia en Internet al permitir que los desarrolladores puedan utilizar
Java para crear aplicaciones multicapas del lado del servidor [1].
Hoy día las APIs de Java Enterprise Edition se han extendido para abarcar
numerosas áreas, como RMI o CORBA para el manejo de objetos remotos,
JDBC para la interacción con bases de datos, JNDI para el acceso a servicios
de directorio y de nombrado, EJB para la creación de componentes de
negocio reutilizables, JMS para la capa orientada a mensajes, JAXP para
el procesamiento XML y JTA para la ejecución de transacciones atómicas,
entre otras tecnologías de JEE [3]. Adicionalmente JEE también soporta
servlets, el substituto en Java para CGI scripts. La combinación de estas
tecnologías permite a los programadores crear soluciones distribuidas para
una gran variedad de aplicaciones de negocios [1].

En 1999 Sun Microsystems agregó un nuevo elemento a la colección de

herramientas Enterprise de Java: JavaServer Pages (JSP). Los JavaServer
Pages se construyen sobre la capa de Java Servlets y se diseñaron para
incrementar la eficiencia con la cual tanto los programadores como los no
programadores pueden crear contenido Web sin necesidad de incrustar
HTML dentro del código Java [2].

Mientras que los servlets pueden ser utilizados para extender la funcionalidad
de cualquier servidor Java, hoy día son más utilizados para extender la
funcionalidad de los servidores Web. Cuando se utiliza un servlet para
crear contenido dinámico para una página electrónica, se está creando una
aplicación Web. Una aplicación Web ofrece una interactividad mayor que
la que ofrece una página Web estática. Una aplicación Web puede ser tan
simple como un buscador de palabras clave en un documento, o tan compleja
como una tienda en línea de comercio electrónico. Dichas aplicaciones se
construyen sobre Internet o en intranets o extranets corporativas, con el
potencial de incrementar la productividad y cambiar la forma en que las
organizaciones de todo tipo realizan actividades de negocios [2].

Los servlets también son la base de múltiples componentes implementados

por los entornos de trabajo o frameworks, como los Action en struts o los
Controllers en Spring [4] y de otros componentes de JEE como se puede
apreciar en la siguiente figura.

La Figura 1 muestra la relación entre las tecnologías Java desarrolladas a partir

de los componentes base: Java Servlets y JavaServer Pages. Los servlets son
clases del lenguaje de programación Java que procesan peticiones de forma
dinámica y construyen respuestas [3]. Las páginas JSP son documentos de
texto que se ejecutan como servlets, pero permiten una aproximación más
natural a la utilizada para crear contenido estático [3].

Figura 1.Relación de las tecnologías Java 7

basadas en servlets. Fuente: Java EE 5
25

Tutorial [3]
 La plataforma JEE utiliza un modelo de aplicación Los arquitectos de aplicaciones JEE necesitan entender
multicapa distribuida para aplicaciones empresariales. más allá de los conceptos de las API como:
La lógica de la aplicación se divide en componentes
de acuerdo con su función. Estos componentes * ¿Cuáles son las mejores prácticas?
pueden encontrarse instalados en diferentes equipos * ¿Cuáles son las malas prácticas?
dependiendo de la capa a la que pertenecen. * ¿Cuáles son los problemas más comunes y las
soluciones probadas a estos problemas?
* ¿Cómo se puede reconstruir el código desde un
escenario menos óptimo, o desde una mala práctica,
hacia una mejor forma, normalmente descrita por un
patrón de diseño?

Los buenos diseños se generan con la práctica y la

experiencia. Cuando éstos son comunicados como
patrones utilizando una plantilla estándar, se convierten
en un mecanismo poderoso para intercambiar
comunicados y obtener beneficios de la reutilización
de componentes, al mismo tiempo se convierten en
una influencia para mejorar la forma en que se diseña y
se construye software [8].

Los patrones representan soluciones expertas a

problemas recurrentes en un contexto y de ahí se
capturan en varios niveles de abstracción y en diversos
dominios [11]. Existen diversas categorías para clasificar
los patrones de software y las más comunes son:
Figura 2.Estructura multicapa para dos aplicaciones web. Fuente:
Java EE 5 Tutorial [3]
* Patrones de diseño
La Figura 2 muestra dos aplicaciones multicapa JEE * Patrones arquitectónicos
divididas en capas, las cuales se describen como: * Patrones de análisis
* Patrones de creación
* Capa Cliente. Componentes corriendo en la máquina * Patrones estructurales
del cliente * Patrones de comportamiento
* Capa Web. Componentes corriendo en el servidor JEE
* Capa de Negocios: Componentes corriendo en el Aún con esta breve lista de categorías, se aprecian
servidor JEE varios niveles de abstracción y esquemas de
* Capa de sistemas de información (EIS). Software clasificación ortogonal [8].
corriendo en el servidor EIS

Aunque una aplicación JEE puede consistir de tres

o cuatro capas, como se muestra en la Figura 2,
las aplicaciones multicapa JEE son generalmente
consideradas de tres capas, ya que se distribuyen en 1 Modelo Vista Controlador - MVC
tres partes: máquina cliente, servidor JEE, y servidores
de bases de datos o sistemas empresariales de
El MVC (por sus siglas en inglés) es un patrón de diseño
información.
de arquitectura de software usado principalmente
en aplicaciones que manejan gran cantidad de
De esta forma, se extiende el modelo estándar cliente-
datos y transacciones complejas, y en donde se
servidor de dos capas, colocando un servidor de
requiere de una mejor separación de conceptos
8 aplicaciones multicapa entre el cliente y el sistema de
para estructurar el desarrollo de una mejor manera y
almacenamiento o bases de datos [4].
25

facilitar la programación en diferentes capas de forma

La amplia adopción de las tecnologías estratégicas de
independiente [7]. MVC sugiere la separación en tres
JEE ha generado estándares abiertos para construir
capas:
arquitecturas basadas en servicios para las aplicaciones
empresariales. Al mismo tiempo, la curva de aprendizaje
en las tecnologías JEE es a menudo confundida con el Modelo: Consisten en la representación de la
aprendizaje del diseño con tecnologías JEE; muchos información que maneja la aplicación. El modelo
de los libros enfocados hacia aspectos específicos de representa los datos puros que, dentro del contexto
la tecnología, no siempre son claros en cómo aplicarla del sistema, proveen de información al usuario o a la
aplicación misma, donde también se encarga de las
[8].
reglas de negocio [6].
Vista: Consisten en la representación del modelo en * Facilidad para agregar nuevos tipos de datos que se
formato gráfico, disponible para la interacción con el requiera por la aplicación, ya que son independientes
usuario. En el caso de una aplicación Web, la vista es del funcionamiento de las otras capas.
una página HTML con contenido dinámico sobre el cual * Independencia de funcionamiento.
el usuario puede realizar operaciones [6]. * Facilidad para el manejo de errores.
* Opciones sencillas para probar el funcionamiento del
Controlador: Es la capa encargada de atender las sistema.
peticiones del usuario, procesando la información y * Facilidad para el escalamiento de la aplicación en
modificando el modelo cuando así se requiere [6]. caso de ser requerido.

El ciclo de vida de MVC se representa por la interacción Las desventajas del patrón MVC
de las tres capas descritas anteriormente con el cliente son:
o usuario.
* La separación en capas incorpora complejidad al
sistema.
* La cantidad de archivos a manejar y desarrollar se
incrementa considerablemente.
* La curva de aprendizaje del patrón es más alta que
usando otros modelos más simples.

La comparación de las ventajas y desventajas de MVC

puede ser muy subjetiva, e incluso ser parte de un
tema a debate, sin embargo, para el objetivo de este
trabajo, la balanza se inclina a favor de MVC.

Actualmente existen diversos frameworks que

implementan MVC en el desarrollo de aplicaciones, pero
su uso requiere de una curva de aprendizaje mucho
más amplia y completa, que incluye el funcionamiento
de dicho framework, por lo que, para el desarrollo de
este trabajo se decidió seguir el esquema que plantea
MVC sin hacer uso de frameworks externos.

Figura 2.Ciclo de Vida MVC. Fuente: [6]

El ciclo inicia cuando el usuario hace una petición al
controlador con información sobre lo que el usuario
desea realizar. Entonces el controlador decide a quién
debe delegar la tarea y es aquí donde el modelo comienza
su trabajo. El modelo se encarga de realizar operaciones
sobre la información que maneja y así cumplir con lo
solicitado por el controlador. Luego de que termina
su trabajo, le regresa al controlador la información
resultante, la cual a su vez se re-direcciona a la vista. La
vista se encarga de transformar los datos en información
entendible para el usuario. Esta información formateada
se envía de regreso al controlador, quién se encarga de
transmitirla al usuario. El ciclo inicia nuevamente cuando
el usuario realiza una nueva petición. 9
25

1.1 Ventajas y desventajas de MVC

Las principales ventajas del patrón MVC son:

* La separación del modelo de la vista, con ello

separa los datos de la representación visual de los
mismos.
* Es más sencillo incorporar múltiples
representaciones de los mismos datos.
 2 Implementación del patrón MVC

Con la finalidad de implementar el patrón MVC sin AccionProxy instancia la clase concreta y ejecuta
ningún framwork externo, se utilizará la tecnología el método que encapsula la funcionalidad. Una
Java Servlets, a fin de implementar las funciones del vez ejecutada la acción, evaluará el resultado y en
controlador y la tecnología JSP para las funciones función de ello, determinará si la petición debe ser re-
de la capa de vista. Para la capa del modelo y las direccionada a otra acción o se debe generar una vista
reglas de negocio se utilizan clases que ejecutan las que será enviada de regreso al usuario.
funcionalidades del ejemplo; dichas clases en algún
momento podrían interactuar con la base de datos, Cabe mencionar que las variantes a esta arquitectura
ya sea aplicando un patrón como DAO o utilizando pueden ser muchas, sin embargo ésta es la que nos
simplemente JDBC; en el ejemplo no mostramos esta permitirá explicar la estrategia de implementación
parte y nos concretamos en explicar el funcionamiento del patrón MVC, la cual puede servir de base para la
del modelo. creación de otro tipo de aplicaciones.

Para el ejemplo de implementación del patrón MVC se La Vista del modelo MVC está compuesta por la página
utilizará la siguiente arquitectura, la cual se muestra en Web a través de la cual el usuario realizará la petición
la Figura 4, donde se aprecian los componentes que de la acción, así como la página que resultará de la
forman parte de esta aplicación de ejemplo. ejecución de la petición.

Tomando en cuenta que la arquitectura de la “solicita_libro_cuento.html” es una página

aplicación debe permitir el desarrollo y mantenimiento HTML que solicita la ejecución de la acción
independiente de sus capas (Modelo, Vista y listarLibrosDeCuentoDisponibles al pulsar el botón del
Controlador), centrando la atención en el flujo de formulario y cuyo código se muestra a continuación.
operación de la capa de negocio (Modelo) y su
interrelación con la capa de presentación (Vista), la
arquitectura queda de la siguiente manera:

En la Figura 4 observamos que el punto de entrada del <form method=”post” action=”SPrincipal”>

modelo es un servlet que llamamos SPrincipal. Este
componente recibe las peticiones iniciales que llegan <input type=”hidden” name=”pAccion” value=”lis
al servidor Web e interpreta el request para obtener los tarLibrosDeCuentoDisponibles” />
parámetros asociados a cada petición.
<input type=”submit” value=”Solicitar libros de
Con esta información el servlet pasa el control a la
cuento disponibles” />
clase AccionProxy, donde, a través del archivo de
configuración AccionConf obtiene el nombre de la
clase que modela la acción para la solicitud recibida. </form>

10
25

En el formulario podemos apreciar que la petición

se realiza a un servlet llamado “SPrincipal”, el cual
recibe un parámetro llamado “pAccion” con el valor
“listarLibrosDeCuentoDisponibles”.
El resultado de la ejecución de esta acción será
Figura 4. Arquitectura para la implementación de la aplicación visualizado por la página: resultado.jsp, la cual se
Web de ejemplo MVC. describe más adelante.
El Control. El servlet “SPrincipal” será el encargado de recibir la petición
realizada desde la página “solicita_libro_cuento.html”. En el servlet, el
método doPost tratará la petición recibida desde el Web con el objeto
request, como se muestra en el siguiente código

<protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException,

IOException {

String parametro, accion = null;

parametro = request.getParameter(“pAccion”);

if(parametro != null && parametro.length() > 0){

accion = parametro;
AccionProxy accProxy = AccionProxy.getInstance();
accProxy.creaAction(request, response, accion);

}
}

Observamos en el código cómo se recupera el parámetro “pAccion” desde

el objeto request para obtener su valor: “listarLibrosDeCuentoDisponibles”.
Si el parámetro es válido, obtenemos la instancia existente de la clase
ActionProxy a la que pasamos el control invocando al método “creaAction”
con los parámetros de la conexión y el valor de la acción solicitada.

Como se puede apreciar, “SPrincipal” se limita a ser el punto de entrada

unificado para todas las posibles peticiones pasando el control al ActionProxy,
desacoplando de esta forma la capa de Vista con la capa de Control.

Una vez transferido el control al ActionProxy, este objeto se encarga de crear

una instancia en tiempo de ejecución de la clase que modela la acción que se
solicita desde la vista y que representa las reglas de negocio.

Para saber qué clase se debe instanciar, el ActionProxy utiliza un archivo

de propiedades con los valores correspondientes a cada acción. El archivo
se llama: “acciones.properties”, el cual es un archivo de propiedades con
la estructura clave=valor donde se declara, para cada acción definida en
la aplicación, la clase Java que modela la funcionalidad asociada a cada
petición. También se declara que se debe hacer cuando termine la ejecución
de la funcionalidad.

11
25
 Las variables que utilizamos dentro del archivo de propiedades
para el ActionProxy tienen las siguientes características:

• “nombre de la acción”.srcAction.Ruta completa de la clase que

modela la acción y encapsula el código a ejecutar.

• “nombre de la acción”.true.resultType. Describe, en caso de

que la acción se ejecute satisfactoriamente, si a continuación se
debe ejecutar otra acción o re-direccionar a la vista. Los posibles
valores son: action para ejecutar una acción, html y jsp para vistas.

• “nombre de la acción”.true.resultValue. Describe, en caso de

que la acción se ejecute satisfactoriamente, el nombre de la
nueva acción a ejecutar o del contenido Web a generar.

• “nombre de la acción”.false.resultType. Describe, en caso que la

acción no sea satisfactoria o produzca un resultado inesperado,
si a continuación se debe ejecutar otra acción o re-direccionar a
la vista. Los posibles valores son: action para ejecutar una acción,
html y jsp para vistas.

• “nombre de la acción”.false.resultValue. Describe, en caso que la acción

no se satisfactoria o produzca un resultado inesperado, el nombre de la
nueva acción a ejecutar o del contenido Web a generar.

El archivo de propiedades para el ejemplo es el siguiente:

listarLibrosDeCuentoDisponibles.srcAction = com.
ro.ejercicioMVC.acciones.ListarLibrosCuento
listarLibrosDeCuentoDisponibles.true.resultType =
action
listarLibrosDeCuentoDisponibles.true.resultValue =
listarCualquierLibroDisponible
listarLibrosDeCuentoDisponibles.false.resultType =
html
listarLibrosDeCuentoDisponibles.false.resultValue =
respuestaInesperada.html
listarCualquierLibroDisponible.srcAction = com.
ro.ejercicioMVC.acciones.ListarOtrosLibros
listarCualquierLibroDisponible.true.resultType = jsp
listarCualquierLibroDisponible.true.resultValue =
respuesta.jsp
12 listarCualquierLibroDisponible.false.resultType =
html
25

listarCualquierLibroDisponible.false.resultValue =
respuestaInesperada.html

En el archivo se observa que la clase “ListarLibrosCuent“ que se

encuentra en el paquete “com.ro.ejercicioMVC.acciones.” es la
clase que modela la funcionalidad solicitada por la acción llamada
“listarLibrosDeCuentoDisponibles” y que una vez que el objeto ejecuta esta
funcionalidad correctamente, se invoca a una nueva acción encadenada, la
cual se llama: “listarCualquierLibroDisponible”.
Por su parte, se declara que la acción “listarCualquierLibroDisponible” está
modelada por la clase “ListarOtrosLibros” también en el paquete: “com.
ro.ejercicioMVC.acciones” y que al finalizar satisfactoriamente su ejecución se
re-direccione a la página: “respuesta.jsp” donde se mostrarán los resultados de
ambas acciones.

Si la ejecución de alguna de estas acciones diera un

resultado inesperado, se re-direcciona al usuario a la página:
“respuestaInesperada.html”.

Controlando estas propiedades, se puede cambiar el flujo de

ejecución de la aplicación de forma sencilla, así como agregar
nuevas funcionalidades e integrarlas con las existentes de
forma clara y sin tener que recompilar la aplicación.

Como se observa en el código del servlet “SPrincipal”, se

crea un objeto de la clase ActionProxy y se invoca al método
“creaAction”, al cual se le envían los parámetros de la conexión
y la acción solicitada desde la Web. El siguiente código muestra
los detalles del método “creaAction”.
public void creaAction (HttpServletRequest request, HttpServletResponse
response, String actionName){
try{
Boolean otraAcc = false;
String nombAcc = actionName;
String tipoRespAccExe,valorRespAccExe = null;
AccionConf confAcc = new AccionConf();
confAcc.setPropertiesPath(“com.ro.ejercicioMVC.acciones”);
do {
String nuevaAcc = confAcc.getProperty(nombAcc + “.srcAction”);
if ( nuevaAcc != null ){ nuevaAcc = nuevaAcc.trim(); }

Accion accion;
accion = (Accion) Class.forName(nuevaAcc).newInstance();
accion.setActionParams(request, response);
Boolean RespAccExe = accion.executeAction();

if (RespAccExe.equals(true))
{
...
} else if (RespAccExe.equals(false)) {
...
}
} while( otraAcc.equals(true) ) ;

} catch (Exception ex) {System.out.println(“ Exception: “ + ex.getMessage() );

}

}
13
25

Una vez que se recupera el archivo de propiedades, se obtiene la propiedad

relacionada con la acción solicitada. Para ello, la clase ActionProxy se apoya
del método “getProperties(String clave)” de la clase ActionConf, al cual se le
pasa la clave para obtener el valor asociado.

La ruta de la clase que modela la acción almacenada en la variable

“nuevaAcc”, se crea con el objeto de la clase de acción correspondiente en
tiempo de ejecución utilizando el método “forName(nuevaAcc)” para cargar
la clase y newInstance() para crear el objeto.
 Una vez creado el objeto y con el uso del polimorfismo valorRespAccExe = confAcc.
a través del método “executeAction” de la super clase getProperty(nombAcc+”.false.
“Accion” se ejecuta el método “execute()” de la clase resultValue”);
correspondiente de acción. Es en este método donde if ( valorRespAccExe != null ) {
realmente se implementa el código específico que se valorRespAccExe = valorRespAccExe.
debe ejecutar para la funcionalidad correspondiente. trim(); }

Una vez que la acción se ha realizado, la respuesta de la if (tipoRespAccExe.equals(“action”))

ejecución se almacena en la variable “RespAccExe” y en {
función de si la acción se ha ejecutado correctamente otraAcc = true;
o no, se recuperan los parámetros correspondientes nombAcc = valorRespAccExe;
(resultType y resultValue) asociados al true o al false y
se crea un nuevo ciclo, en caso de que el resultado sea } else {
una acción o se sale del ciclo principal despachando a try {
la página que corresponda. otraAcc = false;
request.getRequestDispatcher(“/”+
valorRespAccExe).forward(request,
El bloque del código con la evaluación de RespAccExe
response);
es el siguiente:
break;
if (RespAccExe.equals(true)) } catch (Exception e) {System.out.
{ println(“ error en forward: “ +
tipoRespAccExe =confAcc. e.getMessage()); }
getProperty(nombAcc + “.true. }
resultType”);
if (tipoRespAccExe != null ) }
{ tipoRespAccExe = tipoRespAccExe.
trim(); } Al finalizar su ejecución la instancia ListarLibrosCuento
y ser el resultado de la misma positivo/verdadero
valorRespAccExe = confAcc. (en RespAccExe), se evalúan los parámetros de
getProperty(nombAcc+”.true. configuración:
resultValue”); • listarLibrosDeCuentoDisponibles.true.resultType y
if ( valorRespAccExe != null ) { • listarLibrosDeCuentoDisponibles.true.resultValue,
valorRespAccExe = valorRespAccExe.
trim(); } que en este caso indican que el resultado
de esta acción es otra acción de nombre
if (tipoRespAccExe.equals(“action”)) “listarCualquierLibroDisponible”.
{
Así que la variable local nombAcc se carga con el nuevo
otraAcc = true; valor (“listarCualquierLibroDisponible”) y se asigna a
nombAcc = valorRespAccExe; la variable lógica local otraAcc el valor “verdadero”, lo
que implicará que ciclo do-while se reinicie, esta vez
} else { para la nueva acción.
try {
otraAcc = false; Una vez ejecutada la nueva acción, cuando lleguemos
request.getRequestDispatcher(“/”+ al mismo punto donde se evalúan resultType y
valorRespAccExe).forward(request, resultValue encontraremos que la configuración indica
response); que el resultado de esta acción es una página jsp con el
break; nombre “respuesta.jsp”, con lo que a otraAcc se le da el
} catch (Exception e) {System.out. valor “false”, se hace un forward de la vista asociada y
println(“ error en forward: “ + se interrumpe el ciclo.
e.getMessage()); } La clase abstracta “Accion” tiene básicamente tres
14 } métodos:
25

} else if (RespAccExe.equals(false)) • setActionParams: A través del cual las clases que

{ heredan de Accion podrán tener acceso a la request/
response.
tipoRespAccExe =confAcc. • executeAction: Que es le método que será invocado
getProperty(nombAcc + “.false. por AccionProxy sobre la clase de acción concreta
resultType”); haciendo uso del polimorfismo.
if (tipoRespAccExe != null ) • execute: Que es el método abstracto que tendrán
{ tipoRespAccExe = tipoRespAccExe. que implementar todas las acciones “hijas” de esta
trim(); } acción genérica.
El código correspondiente queda de la siguiente manera:
public void setActionParams (HttpServletRequest request, HttpServletResponse
response ){ this.request = request; this.response = response; }
public abstract void execute() throws Exception;
public boolean executeAction() {
boolean resp = true;
try{
execute();
} catch (Throwable ex)
{
System.out.println(“ Exception: “ + ex.toString() + “ en “ + getClass() );
resp = false;
}
return resp;
}

Las clases que implementan las acciones concretas

ListarLibrosCuento y ListarOtrosLibros implementarán
el método execute y en nuestro ejemplo simplemente
van a enviar un mensaje de salida a la Web: un texto
indicando el resultado de la búsqueda de los libros.

El objetivo de este trabajo está centrado exclusivamente

en el flujo de navegación a través de las capas del
modelo MVC.

El código de esta clase es:

package com.ro.ejercicioMVC.acciones;

public class ListarLibrosCuento

extends Accion {
public void execute () {
String informe = “ No hay libros de
cuento disponibles, no se quedarán de
otros géneros”;
request.setAttribute(“LibrosEncontrad
os”, informe);
}
}
public class ListarOtrosLibros extends
Accion {
public void execute () {
String informe = “ No hay libros
disponibles de ningún tipo, todos
están prestados”;
request.setAttribute(“LibrosEncontrad
15
25

os”, informe);
}
}

Para la implementación del ejemplo, se creó un Dynamic

Web Project utilizando Eclipse como entorno de
desarrollo. La estructura del proyecto es la siguiente: Figura 5. Estructura del ejemplo implementado utilizando MVC.
 Referencias
1. Bergsten, H.: Java Server Pages, 2nd
Edition. O’Relly, Sebastopol (2002).
2. Hunter, J., Crawford, W.: Java Servlet
Programming. O’Relly, Sebastopol (1998).
3. Bodof, S. et al.: Java EE 5 Tutorial. Addison-
Wesley, Palo Alto (2010).
4. Green, D. et al.: Java EE 6 Tutorial. Addison-
Wesley, Palo Alto (2011).
5. Modelo Vista Controlador, http://
es.wikipedia.org/wiki/Modelo_Vista_
Controlador (Recuperado el 12 de marzo de
2012).
6. Pavón, J.: Estructura de las Aplicaciones
Conclusiones
Orientadas a Objetos: El Patrón Modelo- En el presente trabajo hemos explicado las ventajas de utilizar un patrón
Vista-Controlador (MVC). In: Dep. Ingeniería
de diseño en el desarrollo de aplicaciones web, como el patrón MVC, sin la
de Software e Inteligencia Artificial,
necesidad de conocer un framework externo y con la finalidad de utilizar
Universidad Complutense Madrid, Madrid
las mejores prácticas para el desarrollo de software, aun con aplicaciones
(2008). http://www.fdi.ucm.es/profesor/
basadas en Servlets y JSP. El ejemplo descrito, nos deja ver unas estrategias
jpavon/poo/2.14.MVC.pdf (Recuperado el 7
de implementación del patrón MVC bajo un esquema sencillo, utilizando las
de marzo de 2012).
ventajas de la programación orientada a objetos y la estrategia de desarrollo
7. Oracle, Model-View-Controller Also
en capas totalmente independientes y desacopladas.
known as MVC, http://www.oracle.com/
te c h n e t wo r k / j ava / mvc - 1 4 0 4 7 7 . ht m l
La arquitectura propuesta nos sirve de guía para el desarrollo de múltiples
(Recuperado el 8 de marzo de 2012).
8. Aulur, D., Crupi, J., Malks, D.: J2EE Patterns: aplicaciones Web, las cuales se podrán elaborar aprovechando las ventajas
Best Practice and Design Strategies. Sun de MVC y de la estrategia de desarrollo en capas independientes.
Microsystems, Cupertino (2005).
9. Stelting, S., Masen, O.: Patrones de Diseño El ejemplo presentado muestra una opción rápida para la aplicación de los
Aplicados a Java. Pearson Education, Santa principios y la implementación de ciertos patrones que, sin duda, ofrecen
16 Clara (2010). una base sólida para el diseño y la arquitectura de aplicaciones confiables
10. Diaz, M.: Ingeniería de la Web y Patrones creadas en forma rápida y con bajo riesgo.
25

de Diseño. Pearson Education, Santa Clara

(2011).
11. Gamma, E., Helm, R., Johnson, R.,
Vlissides, J.: Design Patterns: Elements
of Reusable Object-Oriented Software.
Addison-Wesley, Boston (2000).
12. Ladd, S., Davison, D., Devijiver, S., Yates,
C.: Expert Spring MVC and Web Flow. Apres,
New York (2006).