2009-08-27 16 views
7

Soy nuevo en el desarrollo web y me pregunto acerca de las mejores prácticas para los servlets de Java. ¿Debería cada servlet realizar exactamente una acción, es decir, un servlet para iniciar sesión, un servlet para el registro, etc., o debería buscar combinar acciones similares pasando un parámetro diferente para decirle al servlet qué acción realizar?¿Cuántas acciones debería realizar un servlet?

Saludos

+0

Solo como referencia, cuando las personas hablan de un solo servlet, están pensando en Front Controller Pattern o su adopción específica de Java conocida como MVC Model 2 y si la gente está hablando de múltiples servlets, están pensando en patrón tradicional MVC. – Esko

Respuesta

4

en marcos como Struts hay una sola servlet (aunque podría haber varias instancias de funcionando). Este servlet manejará las solicitudes de varias URL y las pasará de los manejadores de acciones relevantes.

Solo termino escribiendo servlets para servir diferentes tipos de contenido, como un servlet de renderizado de imágenes.

+1

Esto se aplica a casi cualquier marco web moderno. El número de servlets tiende a ser muy limitado (uno o dos para toda la aplicación), y normalmente es implementado por el marco. Escribir servlets desde cero es atípico hoy en día. –

+0

Aunque los archivos JSP están compilados en Servlets por el servidor web. – pjp

+0

La función de Inversión de control de Spring lo hace realmente fácil porque le permite pasar la acción como una clave para un mapa de algún tipo que luego llama al controlador apropiado. Con un poco de herencia puede hacer que su código de servlet sea muy limpio y separar las responsabilidades con mucha facilidad. –

4

Nunca debe pasar argumentos para decirle a un servlet que realice diferentes acciones. Todo lo que está haciendo con eso es combinar 2 servlets en uno, y eso se vuelve más difícil de manejar. Querrá un servlet para cada 'acción'.

Un ejemplo de lo que debe evitar es la siguiente:?

/app/Servlet1 action = edit

if (request.getParamater("action").equals("edit")) { 
//update fields 

} else if (request.getParamater("action").equals("view")) { 
//just query 
} 

Esto tiende a causar muchos problemas aún más cuando se quiere rediseñar nada. Deberá tener servlets separados porque desacopla su lógica para que pueda cambiarla fácilmente en lugar de acoplar sus diversas complejidades de código con las que no debería estar relacionado. Además, mira en Separation of Concerns.

Revisado/edición: Voy a decir esto ahora (mucho más tarde a la respuesta original) ... Puede mantener el concepto de "acciones múltiples" y ponerlo en un solo servlet (controlador). Ese controlador podría y debería delegar en manejadores de acción individuales. Creo que es lo mismo en términos de separación de preocupaciones Y es más limpio que mi respuesta original. En otras palabras, no implemente nada en el servlet, utilícelo solo para el enrutamiento.

1

Prefiero menos servlets y más. Puede usar servlet como un único punto de entrada como en muchos frameworks web. El servlet único recibe todas las solicitudes HTTP y, en función de la solicitud, se selecciona la acción correcta. Ese es el patrón básico del controlador frontal, que creó muchos beneficios como la posibilidad de crear funcionalidades centralizadas con bastante facilidad, como la autenticación, etc .. Aquí hay más información sobre lo siguiente: http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

tienen funcionalidad en muchos servlets solo complica las cosas unnecesserily. Sin embargo, tenga en cuenta que también puede crear un gran lío utilizando solo un servlet si no divide y administra bien su código.

0

Si su aplicación web es lo suficientemente compleja como para que el número de acciones pueda exceder el número de servlets que se siente cómodo manejando, entonces puede considerar un marco web para abstraer el problema .

Su capa servlet sólo debe hacer algunas cosas: entrada

  1. yanqui desde la solicitud
  2. Manejo de estado de sesión
  3. objetos de envío a/de negocios capa de objetos
  4. datos de empuje en la respuesta
  5. Reenviar a una vista
  6. Manejar errores/entrada/salida incorrecta

Casi cualquier otra cosa atrapada en un servlet es una mala idea.

Si sigue algunas pautas simples, un servlet simple puede llamar a un procesador de entrada para convertir los datos de la solicitud y los datos que podrían estar en la sesión en un objeto apropiado. Ese objeto se puede pasar a una capa de BizObject. Esa capa devolverá información que podría almacenarse en la sesión y algún objeto que se pasará a la vista.

Solía ​​hacer cumplir una regla de 40 líneas para los métodos de servicio de servlet. Si pasó más de 40 líneas, esperaba una buena explicación.

Trabajé en una aplicación web Java de 80k líneas que tenía dos servlets, ni excedía las 40 líneas. Manejó alrededor de 60 formas/estados.

En ningún momento pensé que sería más fácil administrar/mantener/modificar la aplicación si hubiera más código en el servlet.

1

Cada servlet debe tener de una a cuatro acciones, denominadas doDelete, doGet, doPost y doPut. Estos nombres corresponden a los nombres de los métodos HTTP DELETE, GET, POST y PUT. Juntos construyen una API REST ful. Utilizará toda la potencia de HTTP si escribe un recurso de servidor con esta interfaz unificada.

Para obtener una API RESTful piense en los recursos como sustantivos con un conjunto de acciones estándar. Terminará con más Servlets (controladores) que con un framework como struts, pero cada servlet tiene solo un número de acciones limeted.

Muchos marcos utilizan el patrón de controlador frontal con un solo servlet que envía una solicitud a un controlador o acción. Pero los controladores de marco o las acciones tienden a duplicar la funcionalidad de la API de servlet. El contenedor de servlets ya es un tipo de controlador frontal, que envía solicitudes a un controlador (un servlet).

+0

Esto va más allá del alcance de la API de Servlet. Solo haga uso de JAX-RS API. – BalusC

+0

JAX-RS es simplemente otra forma de escribir aplicaciones RESTful. La API de Servlet admite REST desde su inicio. JAX-RS es más conveniente si se acepta el uso masivo de anotaciones. – deamon

Cuestiones relacionadas