Ir al contenido principal

Arquitectura J2EE - Patrón MVC

El concepto de reutilización del software, no se ciñe solo a usar las mismas funciones, clases, o métodos para resolver problemas similares, sino que se extiende a otras fases del desarrollo del software como puede ser, como es el caso que nos ocupa en este post, la arquitectura.

En la reutilización a nivel de arquitectura interna, adquieren especial relevancia los patrones de diseño. En concreto, hoy quiero hablar del Patrón Modelo-Vista-Controlador. El MVC es un patrón muy usado en distintos tipos de aplicativos.

He escuchado comentarios de programadores, en los que asocian este patrón a J2EE, dado que hay varios frameworks que lo implementan, como por ejemplo Spring MVC, pero MVC, como el resto de patrones, no es exclusivo de una tecnología. De hecho en las primeras iteraciones de diseño, abstraemos la arquitectura de la tecnología de programación. En Soltel hemos adoptado este patrón en multitud de desarrollos de muy distinta naturaleza: movilidad J2ME, movilidad .NET, C#, y por supuesto en aplicaciones J2EE.

En nuestro día a día, no desarrollamos aplicaciones críticas, donde estaría prohibido usar este tipo de patrones. De hecho dudo que para una aplicación crítica se escoja Java como solución tecnológica.

Para aplicaciones J2EE, la mayoría de las veces, la arquitectura MVC satisface las necesidades de la aplicación. De hecho, creo que se ha constituido como estándar de facto, y si trabajas en proyectos para la administración pública en Andalucía, casi un estándar de iure, ya que en MADEJA (Marco de Desarrollo de la Junta de Andalucía), se recomienda su uso.

A grande rasgos, el patrón indica que se deben establecer tres componentes o capas en la arquitectura, y que cada una de estas, solo se comunica con la adyacente.


- Capa Vista: Responsable de la lógica de presentación y captura de datos de nuestro sistema al exterior y viceversa.
- Capa de Control: Responsable de la lógica operacional de negocio. Traslada las peticiones de la Capa Vista a la Capa de Modelo, y según la respuesta, la redirecciona o no a la Capa Vista. Carga objetos y opera con ellos.
- Capa Modelo: Básicamente contiene la lógica de negocio real, el dominio de la aplicación (VO: Value Object) con sus clases get y set, y los objetos de acceso a datos (DAO) que implementen las operaciones CRUD (Create, Read, Update, Delete). Esto a grandes rasgos, ya que dependiendo de la aplicación, además de los patrones VO y DAO, se puede incorporar un Façade. Esta capa interactúa o bien directamente (por ejemplo, mediante jdbc) o a través de la capa de persistencia, con servidores de bases de datos, LDAP...

Muchos de los frameworks J2EE ya implementan los mecanismos de comunicación entre capas siguiendo MVC.



Usar JSF o Struts para la Capa Vista, Spring para la Capa Controlador, y JPA con Hibernate para la Capa Modelo sería una de las soluciones a la arquitectura de una aplicación J2EE.

Ventajas del patrón
MVC nos aporta una construcción de software muy mantenible, en la que se pueden localizar de forma ágil los errores. Supone un diseño modular, y muy poco acoplado, favoreciendo la reutilización.
Por ejemplo, podemos realizar una interfaz gráfica de escritorio, y una web, que compartirían las capas Controlador y Modelo, y solo trataríamos como desarrollos distintos las dos capas Vista.

Comentarios

  1. Hola, Muchas gracias por la nota!
    podrias enviar un ejemplo de MVC/DAO? algo sencillo como para aclarar toda esta informacion!


    Gracias!

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas.

Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla.

Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que …

¿Por qué Yii Framework?

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos.

Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes.

En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja.

Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en pr…

Scrum para Dummies

Introducción
Scrum es un marco de referencia para desarrollo ágil de productos. Esta metodología se puede aplicar a procesos de producción de distintos sectores, yo me centraré en el de Desarrollo de Software.

Desarrollo tradicional vs Desarrollo Ágil

Especialización vs Equipo Multidisciplinar
Fases vs Solapamiento
Requisitos detallados vs Visión del producto
Seguimiento del plan vs Adaptación a los cambios

Las metodologías tradicionales se ven como una carrera de relevos, en el que cada miembro es responsable de una fase, y hasta que no se termina una fase, es imposible comenzar las siguientes.
En cambio, las metodologías ágiles son más como un partido de Rugby, en el que el empuje conjunto del equipo es importantísimo para el éxito. De hecho, Scrum significa melé.

Ya comparé en un post anterior estos dos tipos de metodologías.

¿Por qué Scrum?
El cliente puede ver resultados desde el primer momento.
Se ahorra el tiempo que en las metodologías tradicionales se dedica en con…