El camino a la web en Java con Play! - Parte 2

Bueno, continuemos con la siguiente entrega de esta saga. Cómo en el post pasado ya los he aburrido pasamos rápido a la (que al parecer llamaré) la sección "a lo que te truje chencha".

A lo que te truje chencha

Demos una vista de vuelta a los directorios en nuestro proyecto:
 

Se fijan cómo en el directorio de la aplicación existe el directorio controllers, cómo les dije en el post pasado este nos sirve para poner los controladores aquí. Ahora, antes de esto, sería chido tener en el IDE de nuestra preferencia pues bien para hacer esto vámonos a una terminal (línea de comandos), dirijámonos al directorio de nuestra aplicación y tecleemos:
Para Eclipse:
 
Para Netbeans:
 
Para IntelliJ IDEA:
 
Y listo, con esto estamos listos para abrir nuestro proyecto con nuestro IDE de preferencia.

Ahora, vamos a nuestro editor o IDE y bajo el directorio controllers, crearemos un controlador con sus respectivas acciones:
 

Cómo ven, dentro de esta clase contamos con algunos métodos especiales cómo lo son "render()" y "redirect()", que no son más lo que dicen ser, render nos envía lo que le pongamos (cualquier objeto) a la vista y redirect nos manda a la url que le pasamos.

Anulando las validaciones faltantes, podemos ver lo simple que es manejar un modelo con Play!, y vemos lo simple que hacemos que un objeto esté disponible en una vista, no hace falta configurar ni nada por el estilo, ahora sólo nos falta enlazar esto aprendido con las vistas, que son un tema más interesante.

Cómo me decía un profe, yo les digo, cascaréenle con los controladores, mañana haremos una vista con uso (poquito) de jQuery, y conforme cresca la saga se irá mejorando este pequeño proyectito.

Saludos.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Sr. Negativo

Modelo Vista Controlador en Play!

Todavía no le entiendo mucho al MVC, en serio los Frameworks no son lo mio

Re: Modelo Vista Controlador en Play!

Pues no tiene nada de difícil:
M (odel) = Definición de entitades.
V (iew) = La representación en interfaz gráfica de lo que envía c.
C (ontroller) = El que interactúa con los modelos y envía las cosas a mostrar a las vistas.

Este patrón no es algo novedoso, @ezamudio (creo) una vez explicó que esto viene de los 80's y más allá. Sin embargo, cómo que mucha gente lo olvidó y emergieron las tecnologías scriplet (JSP, PHP, ASP) en donde ves código cómo:
 

O incluso cosas peores cómo:
 
Y el chile con queso que esto generaba no era más que problemas. Luego poco a poco se mejoró con los taglibs y los EJB. Sin embargo en lo personal lo considero más farragoso, aunque no digo que menos limpio. Se aceptan ahora expresiones JSTL (si estoy mal, favor de corregir) con las que para desplegar valores hace falta un simple ${clase.valor}.

Después de eso y de muchas otras cosas llegaron los frameworks MVC (se popularizaron, porqué se vió que tenía que haber un orden en la manera en que el desarrollador hacía las cosas) cómo algo "innovador" para quitar a los desarrolladores los dolores de cabeza. Y pues es como todo, viene con ventajas y desventajas. Cuestión de cada quien será =D

Imagen de Sr. Negativo

MVC

Según lo que entiendo:

  • Modelo: se refiere a las clases con las que se trabaja
  • Vista: es lo que el usuario ve (las jsp)
  • Controlador: es el "servidor" que atiende peticiones y envia respuestas

Como mencione (arriba) los Frameworks lejos de facilitarme las cosas me las complican (no los se usar bien tal vez).

Una pregunta ¿Es necesario usar JPA, Hibernate (este lo odio mucho), etc. para las bases de datos o existe algo más fácil?

Imagen de beto.bateria

Que tal sr. negativo: Otra

Que tal sr. negativo:

Otra forma de verlo:
Controlador: Es como el gerente de una empresa, solo le gusta mandar.
Modelo: Son los empleados de la empresa, hacen, calculan, obtienen datos.
Vista: Bueno, creo que esta ya quedo clara, serian los vendedores que reciben la info del cliente.

Re: MVC

Pues, mira más bien podemos decir:
M => Clases cómo: Persona, Alumno, Producto, etc. Más no las clases con las que se trabaja (recuerda en Java casi TODO es una clase).
V => Correcto, JSP.
C => Podemos decir que son los servlets.

Ahora, ¿me puedes decir qué es lo que se te hace complicado de Play! o de cualquier otro framework (de tratar aprender Struts 1, te comprendo completamente)?

Con lo de bases de datos, pues la verdad JDBC es bastante sencillo; pero cuando quieres manipular los objetos cómo tablas (en donde 1 objeto es un registro) y no tener problemas con los joins:
 
En este ejemplo, quieres sacar los productos de las ventas realizadas al cliente ?cliente, obviamente, cada venta tiene un detalle (con los productos vendidos en dicha venta). Ahora, el mapping de esta consulta (que es pequeña y de lejos te rasga) es difícil con el ResultSet hacer algo.

En cambio con Hibernate o JPA o cualquier otro motor de persistencia ORM, te encuentras con que la "consulta" es algo cómo:
 

Cómo puedes ver tienes la ventaja de usar todo cómo un objeto, y no cómo un objeto y una base de datos. Claro que sus desventajas tiene y por ejemplo para generar reportes yo no he encontrado mejor manera que con SQL a pelo, para el resto de lo que hago los ORMs me vienen perlas; me ahorro código.

Imagen de ezamudio

MVC

Sr.Negativo: MVC no es un framework. MVC es un patron de diseño, que como ya mencionaste más adelante consiste en separar la aplicación en 3: Modelo (tus entidades, clases de dominio, etc, que puede ser manejado con Hibernate, iBatis, o puro JDBC, como sea), Vista (la interfaz gráfica, que puede ser llevada con jsp, jsf, tapestry, vaadin, gwt, swing, SWT, etc etc etc) y Controlador (la parte que coordina entre modelo y vista, donde reside toda la lógica de negocio, esto lo puedes llevar con EJB's, Spring, Weld, etc).

Hay frameworks que llevan una de esas 3 partes, hay otros que llevan 2, y hay algunos que abarcan las 3. Y hay otros que implementan otros patrones de diseño, porque no es la única manear de separar las funciones de una aplicación (existe el modelo multicapas por ejemplo).

Imagen de Sr. Negativo

Re:MVC

@ezamudio

No me refería a que MVC fuera un Framework, me refería a Play! (y a otros Frameworks como Spring).

Aprovechando, una pregunta que tengo : ¿Es realmente necesario usar un Framework para realizar aplicaciones web Java?

@Sr. Negativo: El MVC es un

@Sr. Negativo: El MVC es un patron que te dice "separa los niveles de programación" nunca te dice que utilices X, Y o Z

Los frameworks son otras cosas que nada podrían tener que ver con MVC... Los frameworks son herramientas. Una vez escuche alguien decir que un framework es como un Garage con todas las herramientas esas herramientas que puedes utilizar para arreglar una silla, una mesa, un buró... etc, depende todo a que esté orientada la funcionalidad de tu framework

Puedes utilizar Frameworks sin seguir MVC, como? supon que en una clase procesas tu peticion HTTP, es esa misma clase accesas a la informacion e imprimes tu HTML... si usaste un frramework, solo basta que obtengas el printWriter para hacer eso en una clase pues tooooodos los frameworks MVC no son mas que un servlet (con los dotes que tenga el framework). Supon que en ese ejemplo usaste Hibernate + Play y de una vez le metes otro Framework Ajax o lo que quiereas... estas de acuerdo que aunque usas frameworks no estas siguiendo el patron? Porque estas mezclando la obtencion de datos con el procesamiento de datos y la visualizacion de datos... de que te sirvio el framework pues nada mas de facilitarte la conexion a la DB

Tambien pasa que sin frameworks puedes usar MVC... haste una clase que se conecte a tu base de datos, te regresa la instancia de conexion y luego haces tu dao que invoque esa clase y luego haces tu clase de procesamiento, haces un servlet que invoque esa clase de procesamiento y finalmente en un jsp puedes pintar tu resultado...

por cierto alguna vez lei una entrada sobre este tema...

COnclusion, MVC no te exige frameworks, y los frameworks no te exigen MVC

MVC: Sugiere la forma en que tienes que organizar tu proyecto por "capas"
Framework: Garage dotado de herramientas de acuerdo al enfoque del mismo framework

Imagen de ezamudio

Framework

Pues depende de tu definición de framework. JSP podría ser considerado un framework, muy rudimentario, pero framework a fin de cuentas. El simple hecho de tener un contenedor JEE o despachador de servlets tipo Tomcat o Jetty, y que tengas una infraestructura puesta ahí para que nada más tengas que hacer un servlet y pueda despachar peticiones de web, podría decirse que eso ya es un framework por sí mismo.

Obvio puedes saltarte todo eso y hacer tu propio web server, tu propio contenedor, minimalista y ad-hoc para que solamente haga lo que necesitas. Si vas a hacer eso pues no tiene caso que uses Java, lo mejor será que hagas todo en ensamblador y será mucho más rápido.

Si vas por el camino de Java, y decides que no vale la pena hacer tu propio web server y contenedor, entonces puedes usar servlets. Si decides que te da mucha flojera generar páginas con puro servlet, entonces puedes usar JSP. Si decides que los JSP solitos son muy rudimentarios, puedes agregarles JSTL. Luego cuando decidas que aún así hay cosas que es un verdadero relajo armar y que haces una y otra vez, puedes integrar algo como Struts. O aprender de JSF y usar alguna implementación.

O tal vez a esas alturas ya entendiste lo suficiente de desarrollo web como para darte cuenta que todo el modelo de JSP está jodido y buscar alternativas, como GWT, Wicket, Tapestry, Play, Click, etc que desechan por completo el modelo de servlets/jsp y ofrecen un paradigma alterno, una manera distinta de lograr lo mismo. Tal vez escojas algo que nada más te resuelva la parte de presentación (la maldita V).

Y luego puede que te hartes de estar manejando tus componentes y de estar implementando el singleton en cada uno o de meterlos a mano en JNDI para poder accesarlos y tener que hacer una interfaz por cada clase y cosas así, y de repente le echas un ojo a Spring y se te hace atractivo porque resuelve precisamente ese problema. Para entonces tal vez ya estés usando Hibernate, iBatis, JPA, JDO, TopLink o algún otro ORM porque ya te habías hartado de estar manejando JDBC a bajo nivel para todas tus aplicaciones.

O puede que odies todos esos frameworks porque en el camino tú hiciste tu propio framework, porque pues ya construiste un montón de cosas encima de JSP, encima de JDBC, algo para manejar componentes, etc etc. Y entonces no necesitas usar ninguno de esos frameworks porque tú ya tienes tu propio framework que tú hiciste. Está bien si eso es lo que logras.

A lo que voy es que no es obligatorio que uses uno o varios frameworks, ni para desarrollo web ni para Swing ni para móviles ni nada. Siempre puedes empezar de cero, hacer de cuenta que eres la primera persona que va a usar JSP y cada que te topes con un problema, hacer como que nadie nunca se ha topado con ese problema y tratar de resolverlo tú solo, echando más y más código. Pero, es bueno que sepas que hay mucha gente en el mundo que ya se ha topado con muchos de esos problemas y los han resuelto de distintas formas y muchos están compartiendo sus soluciones y están a tu disposición. Algunos incluso han tenido más tiempo y dedicación y le pensaron y le pensaron hasta encontrar una mejor forma de atacar algún problema, de darle la vuelta por completo, cambiando totalmente la forma en que normalmente se hacían las cosas en cierta plataforma. Y lo comparten y está a tu disposición, en forma de frameworks.

Una advertencia muy importante en caso que te vayas por la otra opción, de hacer todo tú y crear tus propios frameworks: documenta muy bien todo y consigue permisos ESCRITOS de las empresas para las que trabajas. Si eres empleado, todo el código que escribas en tu chamba le pertenece a la empresa para la que trabajas (y el código que escribas en tu tiempo libre tal vez también, dependiendo del contrato; si no está especificado, hazte a la idea que te lo pueden quitar, registrarlo ellos; a ver quién puede pagar mejores abogados si es que se pone fea la cosa). Si eres independiente, deja muy claro y por escrito en los contratos que hagas para tus clientes, qué código es el que hiciste para ellos y que por tanto es una obra por encargo y les pertenece, y qué código es el que tú ya traías y que te pertenece porque ya incluso lo registraste en INDAUTOR y ya lo tenías desde antes de comenzar el proyecto y por lo tanto eso no es de ellos (y tienes que decirles bajo qué licencia se los estás dando entonces, y qué pueden hacer con ese código en el futuro si es que alguien más le mete mano a la aplicación que les hiciste, etc).