domingo, 20 de mayo de 2012

Arquitectura sencilla Java Web

 

Acá les dejo un diagrama genérico de las tecnologías que son mas comunes para mi y que he visto que se usan en arquitecturas para desarrollo de Java Web, de Java EE puedes encontrar mucho en internet, pero este tipo de diagramas no son muy comunes de echo busque mucho y no lo encontré ahora que lo voy a usar lo subo para que este en la web y puedan checarlos, en caso de que tengan algún comentario, alguna pregunta o alguna corrección o que les parezca que el diagrama puede crecer solo coméntenlo ya sea por los comentarios o mandando mail y con gusto lo vemos o aclaramos dudas, espero les sea de mucha utilidad.

Mas adelante intento explicar lo más resumido posible las funciones de las capas y las tecnologías como un extra ya que puedes encontrar su definición fácilmente en la web.

[Espero que se sobreentienda que los globos son descriptivos y los post-it son comentarios].

Modelo de Arquitectura Java Web

 

Toda la arquitectura basada en la arquitectura MVC [Modelo-Vista-Controlador] y el punto en el que entran otras tecnologías como Hibernate y Spring.

La Vista[View] en la que regularmente [dependiendo del framework que se implemente] se usan Java Server Pages [JSP] vendría siendo la interfaz con el usuario.

 

Plataforma basica de vista Java Web

así es como se manejarían regularmente las plataformas sobre las que trabajaría el modelo de Java Web, aprovecho para resaltar que la Base de Datos se encuentra en un servidor diferente al resto del modelo [en el modelo anterior].

 

El Controlador[Controller] tiene la única función básica de redirigir las llamadas de la vista [prácticamente lo que solicita el usuario] al servicio correspondiente y entregar la respuesta correcta según la ejecución del proceso del servicio [el termino de servicio se explica mas adelante]; como comentario en Spring los controladores son representados por Servlets que son clases java, aunque me comentan que en Struts los Actions no son considerados como Controlador y que probablemente serían los archivos de configuración XML los que llevarían esa función, independientemente de eso el principio debe ser el mismo, de funcionar como mediador entre la vista y el modelo[o servicios el caso].

 

El Modelo[Model] es el que guarda la abstracción de objetos reales como objetos de POO, aquí es donde se implementa toda la lógica de negocio representada con Entidades[Entity] o POJO [o piojos como les llama mi hermano XD] esto representa la base de la POO y la cual regularmente no se implementa! ya que este tipo de abstracción se realiza muy comúnmente en la Base de Datos y posteriormente por medio de las tecnologías como Hibernate se hace el mapeo automático de la Base de Datos a las Entidades Java[más adelante se explica a fondo esto] esto implicaría que si has dedicado mucho esfuerzo en POO y la abstracción de objetos reales en clases Java no te sea muy útil ese conocimiento  (u.u*).

La capa de Servicio[Service] aunque no corresponde al patrón MVC regularmente se implementa como un gestor de procesos, digamos que en el escenario típico de Universidad-Maestro-Alumno-Materia, nosotros tenemos mapeados nuestros POJO’s  en el modelo, y un proceso de la aplicación es que el alumno cambio de materia, el servicio es el que se encargaría de esto ya que se encarga de los procesos, en este caso sería un proceso el que se encargaría de tomar el alumno eliminar la materia que tiene asignada y asignarle la nueva así como sus implicaciones como cambiar de maestro, etc. Uno de los puntos claves de los servicios y por lo cual lo puedes identificar fácilmente es por tener la capacidad de manejar varios POJO’s o entidades dentro de un mismo proceso, en este ejemplo el servicio manejaría al alumno y 2 materias diferentes pero el proceso de persistencia a la Base de Datos de los cambios realizados se lo cede a la capa de DAO.

 

La capa de DAO[Data Access Object] como ya se comento se encarga de la persistencia de las entidades a la Base de Datos, puedes ubicarlos por 2 funciones principales. La primera se encarga de las operaciones CRUD[Create,Read,Update,Delete] de las entidades es decir: Altas, Consultas, Cambios y Bajas [ABC]. Y la segunda característica es que por best practice 1 DAO solo se encarga de las funciones CRUD de 1 Sola Entidad o POJO, en la practica se ve muy comúnmente mapeada la entidad de Alumno.java con su DAO AlumnoDAO.java y Maestro.java con su DAO MaestroDAO.java, etc.

 

La IoC[Inversion de Control] me pareció un punto importante por eso lo indico en el diagrama, regularmente se implementa con el framework Spring Core o JSF que son los únicos que conozco que implementan este patrón, el patrón básicamente funciona a base de Singletons y tiene como objetivo ahorrar recursos del servidor además de otros, el patrón de Singleton lo puedes consultar en la Web pero su objetivo básico es que solo exista una instancia de una clase a lo largo de toda la aplicación; en general el objetivo del patrón IoC busca que cada clase que se genere dentro de cada capa de la aplicación [todas las que hemos mencionado] que maneje clases Java [en el modelo indicado por el recuadro de nombre java] solo se instancie 1 sola vez a lo largo del ciclo de vida de la aplicación y en la practica se identifica muy claramente con la ausencia de llamadas al constructor de estas clases, es decir en código nunca mandaras llamar un <code> new AlumnoDAO();</code> si no que el framework inyectará la dependencia por ti para que solo hagas uso de ella sin tener que llamar a su constructor.

 

Lo que indico en el diagrama como Java-HTML Converter y Java-JavaScript Converter [aclaro que es un nombre arbitrario que les di para indicar su función] sirven básicamente para lo mismo, transferir información de la vista al controlador y viceversa ya que regularmente en la vista no se maneja código java [aunque sea posible por los JSP] sino que mediante tags HTML o llamadas a funciones JS[JavaScript] se intercambia información entre la vista y el controlador que sí es código java pudiendo transferir desde datos primitivos como tipos de Dato Objeto. No confundamos la tecnología MVC[que es el único nombre con el que la he oído, por eso le llamo así] con el patrón MVC, la tecnología MVC sirve para la comunicación entre vista y controlador y el patrón MVC es básicamente el núcleo del post. La diferencia entre la tecnología MVC e implementar AJAX, es que mediante la tecnología MVC solo puedes acceder al intercambio de información mediante GET o POST para lo cual siempre se necesita refrescar la pagina del explorador de internet del cliente, mientras que mediante AJAX puedes realizar el intercambio de información mediante JS [asíncronamente]  con las desventajas que también implica hacerlo por JS.

 

Lo que nombro como Java-SQL Tables Converter es en realidad una tecnología llamada ORM[Object Relationship Maping] cuya función principal es mapear de la siguiente forma las entidades de Bases de Datos a Entidades Java. Espero que el diagrama se explique por sí mismo, la idea es que el ORM mapea cada tabla de la Base de Datos como clases y los campos de cada tabla como atributos de cada clase, de tal manera que cada fila o registro de la Base de Datos representa un Objeto en java!

ORM

Acá un ejemplo mas complejo para que analices las relaciones de las tablas mapeadas a clases. En realidad las clases son Java Beans por eso se mapean con sus getters y setters.

Diagrama Entidad RelaciónDiagrama de Entidades

 

Bueno espero que el post les sea de utilidad a muchos, si es así comenten o compartan o den like o lo que gusten ^^ hasta pronto.