java - programacion - ¿Cuándo usas un JSP y cuándo un servlet?
paginas web en java ejemplos (13)
De acuerdo con todos los puntos anteriores sobre las diferencias entre JSP y Servlets, pero aquí hay un par de consideraciones adicionales. Usted escribe:
Tengo una aplicación que envía al cliente a otro sitio para manejar los pagos. El otro sitio, fuera del cliente, llama a una página en nuestro servidor para informarnos cuál es el estado del pago. La página llamada comprueba los parámetros que proporciona la aplicación de pago y comprueba si conocemos la transacción. Luego actualiza la base de datos para reflejar el estado. Todo esto se hace sin ninguna interacción con el cliente.
Su aplicación está consumiendo el servicio de pago de otra aplicación. Su solución es frágil porque si el servicio de pago en la otra aplicación cambia, eso rompe su página JSP. O si desea cambiar las políticas de pago de su aplicación, entonces su página deberá cambiar. La respuesta breve es que su aplicación debe consumir el servicio de pago de la aplicación a través de un servicio web. Ni un servlet ni una página JSP son lugares apropiados para poner su lógica de consumo.
En segundo lugar, a lo largo de esas líneas, la mayoría de los usos de páginas servlets / JSP en los últimos años se han colocado dentro del contexto de un marco como Spring o Struts. Recomendaría Spring, ya que le ofrece la pila completa de lo que necesita desde las páginas del servidor hasta la lógica del portal de servicios web para los DAO. Si quieres entender los aspectos prácticos de Spring, recomendaría Spring in Action . Si necesita comprender mejor cómo clasificar una arquitectura empresarial en un lenguaje como Java (o C #), recomendaría los Patrones de arquitectura de aplicaciones empresariales de Fowler.
Esta pregunta ya tiene una respuesta aquí:
- ¿Cuál es la diferencia entre JSF, Servlet y JSP? 16 respuestas
Tengo una aplicación que envía al cliente a otro sitio para manejar los pagos. El otro sitio, fuera del cliente, llama a una página en nuestro servidor para informarnos cuál es el estado del pago. La página llamada comprueba los parámetros que proporciona la aplicación de pago y comprueba si conocemos la transacción. Luego actualiza la base de datos para reflejar el estado. Todo esto se hace sin ninguna interacción con el cliente.
Personalmente, he decidido implementar esta funcionalidad como JSP ya que es más fácil simplemente colocar un archivo en el sistema de archivos que compilar y empaquetar el archivo y luego agregar una entrada a un archivo de configuración.
Teniendo en cuenta la funcionalidad de la página, supongo que un servlet sería la opción preferida. La (s) pregunta (s) son:
En el servlet de java, las etiquetas HTML están embebidas en codificación java. En JSP, las codificaciones java están incrustadas en etiquetas HTML.
Para una gran aplicación para grandes problemas, el servlet es complejo de leer, comprender, depurar, etc. debido a la imposibilidad de incorporar más etiquetas html dentro de la codificación java ... Así que usamos jsp.In jsp es fácil de entender, depurar, etc.
Gracias y saludos, Sivakumar.j
En una arquitectura MVC, los servlets se utilizan como controladores y JSP como vistas. Pero ambos son técnicamente iguales. JSP se traducirá a servlet, ya sea en tiempo de compilación (como en JDeveloper) o cuando se acceda por primera vez (como en Tomcat). Entonces la verdadera diferencia está en la facilidad de uso. Estoy bastante seguro de que tendrá problemas para representar la página HTML con servlet; pero, frente al sentido común, en realidad te resultará bastante fácil codificar incluso una lógica bastante compleja dentro de JSP (con la ayuda de alguna clase de ayuda preparada tal vez). Los chicos de PHP hacen esto todo el tiempo. Y entonces caen en la trampa de crear códigos de spaghetti. Así que mi solución a su problema: si le resultó más fácil codificar en JSP y no implicaría demasiados códigos, siéntase libre de codificar en JSP. De lo contrario, use servlet.
Hay 2 reglas bastante simples:
- Siempre que quiera escribir código Java (lógica comercial), hágalo en una clase Java (por lo tanto, servlet).
- Cuando quiera escribir código HTML / CSS / JS (ver / lógica de plantilla), hágalo en un JSP.
Pregunta relacionada:
JSPs: Para presentar datos al usuario. Ninguna lógica comercial debe estar aquí, y ciertamente no tiene acceso a la base de datos.
Servlets: para manejar la entrada de un formulario o URL específica. Por lo general, las personas utilizarán una biblioteca como Struts / Spring en la parte superior de Servlets para aclarar la programación. Independientemente del servlet solo debe validar los datos que han ingresado, y luego pasarlos a una implementación de capa de negocio back-end (que puede codificar casos de prueba contra). Luego debe poner los valores resultantes en la solicitud o sesión, y llamar a un JSP para mostrarlos.
Modelo: un modelo de datos que contiene los datos estructurados que maneja el sitio web. El servlet puede tomar los argumentos, ponerlos en el modelo y luego llamar a la capa de negocios. El modelo puede interactuar con DAO de back-end (o Hibernate) para acceder a la base de datos.
Cualquier proyecto no trivial debe implementar una estructura MVC. Es, por supuesto, excesivo para la funcionalidad trivial. En su caso, implementaría un servlet que llamara DAO para actualizar el estado, etc., o lo que sea necesario.
La mayoría de las aplicaciones de Java en la actualidad se basan en el patrón MVC ... En el lado del controlador (servlet), implementa la lógica comercial. El controlador de servlet suele reenviar la solicitud a un jsp que generará la respuesta html real (la Vista en MVC). El objetivo es separar las preocupaciones ... Se han escrito miles de libros sobre ese tema.
Las JSP se deben utilizar en la capa de presentación, los servlets para la lógica de negocios y el código de back-end (generalmente la capa de la base de datos).
No conozco ningún motivo por el que no pueda usar un JSP como lo describe (el compilador lo compila a un servlet de todos modos), pero tiene razón, el método preferido es hacerlo un servlet en primer lugar .
Las JSP son esencialmente marcas que automáticamente se compilan en un servlet por el contenedor de servlets, por lo que el paso de compilación se producirá en ambas instancias. Esta es la razón por la que un contenedor de servlets que admite JSP debe tener el JDK completo disponible en lugar de solo necesitar el JRE.
Entonces, la razón principal para JSP es reducir la cantidad de código requerido para representar una página. Si no tiene que renderizar una página, un servlet es mejor.
Las JSP son un atajo para escribir un servlet. De hecho, están traducidos al código java del servlet antes de la compilación. (Puedes consultarlo debajo de algún subdirector de tomcat que no recuerdo el nombre).
Para elegir entre servlet y JSP, utilizo una regla simple: si la página contiene más código html que java, vaya a JSP; de lo contrario, solo escriba un servlet. En general, esto se traduce aproximadamente a: usar JSP para presentación de contenido y servlets para control, validación, etc.
Además, es más fácil organizar y estructurar su código dentro de un servlet, ya que utiliza la sintaxis de la clase Java simple. Las JSP tienden a ser más monolíticas, aunque es posible crear métodos dentro de ellas.
Sé que esta no es la respuesta popular hoy, pero: cuando estoy diseñando una aplicación desde el principio, siempre uso JSP. Cuando la lógica no es trivial, creo clases Java normales para hacer el trabajo pesado que llamo desde el JSP. Nunca entendí el argumento de que debería usar servlets porque, como clases de Java puro, son más fáciles de mantener. Un JSP puede llamar fácilmente a una clase pura de Java y, por supuesto, una clase Java normal es tan fácil de mantener como cualquier servlet. Es más fácil formatear una página en un JSP porque puede poner todo el marcado en línea en lugar de tener que escribir un montón de println. Pero la mayor ventaja de los JSP es que puedes soltarlos en un directorio y se puede acceder directamente a ellos: no tienes que preocuparte por establecer relaciones entre el URL y el archivo de clase. La seguridad se maneja fácilmente haciendo que cada JSP comience con una comprobación de seguridad, que puede ser una declaración de llamada única, por lo que no es necesario colocar la seguridad en una capa de despacho.
La única razón por la que puedo ver para usar un servlet es si necesita una asignación compleja entre las URL y la clase de ejecución resultante. Por ejemplo, si desea examinar la URL y luego llamar a una de muchas clases dependiendo del estado de la sesión o algo así. Personalmente, nunca quise hacer esto, y las aplicaciones que he visto que sí lo hacen tienden a ser difíciles de mantener porque, antes de que puedas comenzar a hacer un cambio, debes averiguar qué código se está ejecutando realmente.
Sí, esto debería ser un servlet. Un JSP puede ser más fácil de desarrollar, pero un servlet será más fácil de mantener. Solo imagine tener que arreglar algún error aleatorio en 6 meses e intentar recordar cómo funcionó.
Un JSP se compila a un servlet la primera vez que se ejecuta. Eso significa que no hay diferencia de tiempo de ejecución real entre ellos.
Sin embargo, la mayoría tiene una tradición de usar servlets para controladores y JSP para vistas. Como los controladores son solo clases de Java, puede obtener el soporte completo de la herramienta (finalización del código, etc.) de todos los IDEs. Eso da una mejor calidad y tiempos de desarrollo más rápidos en comparación con los JSP. Algunos IDE más avanzados (IntelliJ IDEA viene a la mente) tienen una gran compatibilidad con JSP, haciendo que ese argumento sea obsoleto.
Si está creando su propio marco de trabajo o simplemente lo está haciendo con JSP simples, entonces debe sentirse en libertad de seguir usando los JSP. No hay diferencia de rendimiento y si cree que las JSP son más fáciles de escribir, continúe.
creo que depende de usted? porque JSP es Java dentro de HTML y Servlet es un Java que puede hacer el HTML dentro
hmmm ... servlet es más seguro que jsp porque si se envía a Servlet y se reenvía a otra JSP, no aparece la extensión de archivo y tampoco se puede ver en qué página se encuentra.
pero la ventaja de JSP es que puedes codificar allí fácilmente.