jsp <---> servlet [escencia? finalidad?]

[mesiasdiabolico]

bueno quisiera si alguno de los tantos expertos de este foro puede aplicar un poco de claridad conceptual a este combo....

realmente no termino de entender el pq de esta division al momento de programar un frontend...

por momentos me parece un esquema algo obsesivo no creen? alguno puede clarificarme? cuando realmente veo las ventajas de este esquema de trabajo?

pq no hacer la invocacion a los Bussiness Objects directamente desde mi JSP? seguramente estoy pifiando en algo en este analisis debido a mi inexperiencia.....

help!

[goncafa]

Priemro que nada, ya debes saber que la tecnologia de Java para el lado del servidor son los Servlets.

Cuando los Servlets salieron a la luz para poder hacer reemplazo a la tecnologia CGI que ahora era reemplazada por la tecnologia Servlets la cual era mucho mas potente, la gente de SUN y de la JCP se dieron cuenta que los Servlets eran una solucion un tanto complicada de programar, puesto que cualquiera que quiciera trabajar con ellos debia saber Java a nivel muy avanzado, puesto que estos son una clase de Java como cualquier otra, ademas debian entender los conceptos de orientacion a objetos para poder sacar el provecho y entender realmente como esta tecnologia funciona. Fue cuando se dieron cuenta que si quierian entrar en el mercado, debian de simplificar el desarrollo de los mismo, fue cuando se crearon las Java Server Page o JSP, las cuales puedes escribirlas entre mezclando codigo Java mediante scriptles (<% %>) junto al codigo HTML de una pagina, esto hace mucho mas simple el poder escribir los servlets. Las JSP luego, la primera vez que un usuario lo solicita al servidor es traducido a una clase Java Servlets por el contenedor de Servlets, luego es compilada y puesta en memoria y esta la que le llega al navegador, para Java, como si de otro Servlets se tratara, pero para el programador, como si de una pagina HTML sencilla lo fuera.

Pues bien, ya sabiendo que tanto cuando hablas de Servlets como cuando hablas de JSP, finalmente estamos hablando de lo mismo, ¿Por que entonces no hacer todo directamente en la JSP como dices tu?
Aqui entra en juego otro cuento, si tu quieres puedes perfectamente hacer llamado a tus objetos y demaces directamente en la JSP, sin embargo estas pasando por alto los patrones de diseño, los cuales buscan simplificar el mantenimiento de las mismas, la seguridad del codigo y la reutilicacion del mismo. Es por eso que cuando se hace software profesional se separa todas las vistas (Lo que el cliente ve) de como se hacen las cosas (Modelo de engocio), de esta forma si aplicas un modelo como por ejemplo el MVC (Modelo Vista Controlador) tu pagina en si la puede diseñar un diseñador grafico, pero que pasaria si le entregas a el una pagina JSP con codigo Java dentro? Lo mas probable es que el diseñador se confunda y le cueste hacer su parte, que pasaria ademas si ese codigo es codigo de negocio? una parte vital de tu aplicacion, y el diseñador o tu mismo al estar editando la parte vista pasas a llevar un simple puntoy coma? podrias causar una catastrofe a nivel de sistema y podrias jamas llegar a encontrar el error. Todo esto se evita cuando usas un buen patron para el diseño de tu arquitectura, donde esto esta separado en su debida capa, y ninguna capa tiene idea de la existencia de la otra, pero todas funcionan para un mismo fin, jamas volveras a peligrar tu modelo de negocios al trabajar tu capa vista. Por otra parte el mantenimiento es mucho mas sencilllo, cuando necesites editar el como haces algo, una conexion a una base de datos o lo que sea, solo iras a la capa de negocio y encontraras solo codigo de negocio y no cosas que no son de ahi, lo cual es un ahorro enorme de esfuerzo. Podrias tambien querer en un momento cambiar el diseño visual de tu aplicacion, y ahora solo deberas editar la capa vista, sin tocar los otros componentes.

Por esto y por muchas razones mas es que se hace tanto enfacis en separar las cosas y que trates de dejar la minima cantidad de codigo Java en tus JSP. Yo por ejemplo, uso Struts, y en mis paginas JSP existe 0% de codigo Java, para eso estan la JSTL.

Saludos

[mesiasdiabolico]

muchas gracias señor muy clara su respuesta

es lo q pensaba q se trataba de quitar diseño de algoritmos....

de todas maneras sigue sin cerrarme, es decir en algun momento siempre es necesario solicitar las consultas al servlet o a la DB o donde sea....

entonces pienso si esa sobrecarga y mania de abstraccion no termina siendo un vicio....

seguramente si hiciera pruebas con struts lo entenderia mejor

por el momento el unico modelo que reconozco de pokisimo acople diseño datos es el tandem xml - xls...

struts es similar??

kiero decir si en algun momento de mi JSP necesito hacer un loop para recorrer una coleccion de resultados, no veo el sentido de encapsular el servlet que en definitiva termina haciendo lo mismo y agregando "lentitud" a mi app...

me expliko?

salu2

[goncafa]

Pues no, si usas por ejemplo estruts, puedes reducir tu codigo java en JSP a cero, existen etiquetas JSTL predefinidas por Struts para todo lo que necites como por ejemplo recorre un Loop de Objetos.

Lo que dices de pedir recursos, la JSP solo los pide, el controlador (Un Servlet) deriba la peticion y valida si es necesario, esta peticion puede ir a un EJB, a otro Servlet, a donde sea, y luego la respuesta la retorna al JSP generando la vista correspondiente. De esta forma las JSP jamas sabran del modelo de negocios, ellos solo tratan con el controlador que es su intermediario, a la vez, el modelo de negocio jamas sabe de las JSP por la misma razon, por obvio entonces queda, que luego podrias querer hacer un sistema similar o que use las mismas funciones para otra aplicacion ya sea web o no, y el modelo de negocios no tendras ni que hacerlo denuevo ni nada. Lo mismo con las vistas.

Saludos

[stock]

cuando te metas con struts entenderas perfectamente el uso de las capas, y que decir de appfuse en fin JAVA es todo un mundo por conocer!!