¿Uno o múltiples servlets por aplicación web?

Question

Lo sé, depende de la aplicación web. Pero en el caso normal, ¿qué haces?: Un servlet, que sirve diferentes páginas (como una aplicación independiente con contenido variable) o para cada página un único servlet.

Tome por ejemplo un blog. Está la página de inicio con las entradas de blog más recientes, una vista de artículo para mostrar una entrada de blog y un archivo. Implementa esto con tres servlets diferentes, o uno que está enviando a las funciones. Al menos una buena parte de las cosas se comparte, como los encabezados http.

¿Cuáles son sus experiencias, qué funciona mejor?

Answer 1

Normalmente creará un servlet por caso de uso. Los servlets actúan como controladores para su aplicación. Cuando identifique una interacción de un usuario, implemente un servlet para controlar esa interacción.

Es decir, si está utilizando servlet plano/JSP para construir el sitio. Si está utilizando un marco como struts, encontrará que implementan el patrón de controlador frontal y usan un solo servlet que recibe todas las solicitudes y las reenvía a clases de acción que implementan la lógica real de la solicitud del usuario. esto es mucho más difícil de hacer por ti mismo, pero es una buena práctica ... es la razón por la que tantas personas usan estos marcos.

Así que la respuesta corta es que creará muchos servlets por aplicación web ya que cada aplicación web expondrá varios casos de uso.

[EDIT] Volver a leer su pregunta parece que está utilizando el término sitio para indicar página o ver. De nuevo, depende de lo que está sucediendo en esa vista. Por ejemplo, para mostrar la entrada de blog más nueva, puede tener un servlet que construya la lista de entradas de la base de datos para su visualización. Si el usuario hace clic en una entrada, entonces otro servlet puede recuperar esa entrada única para ver y así sucesivamente. Principalmente, cada acción es un caso de uso, por lo tanto, un servlet diferente.

Answer 2

La mayoría de los marcos web usan un servlet despachador (por ejemplo, Spring MVC) que se encarga de las solicitudes de enrutamiento a las clases/controladores correspondientes.

Cuando empiezas a tener muchas páginas, este enfoque funciona mejor porque tienes una forma más amigable para el usuario (con respecto a web.xml) de declarar/administrar una clase que maneja las solicitudes http y su url. Ejemplo (primavera mvc otra vez):

@Controller 
public class MyController { 
@RequestMapping("/viewPosts") 
public void doViewPosts(HttpRequest r, HttpResponse res) { 
    //... 
} 
} 

Además, tener un servlet despachador mantiene el flujo de código centralizado.

Answer 3

Depende.

En mis últimos proyectos, he implementado un solo servlet que delega en varios objetos de tipo servlet que se instancian en forma de inyección de dependencia. Por ejemplo, tengo algo como esto en mi servlet (pseudo-código):

for(Handler handler : handlers) { 
    if(handler.handle(request, response)) { 
     return; 
    } 
} 

donde el manipulador es una interfaz con un mango booleano (petición y respuesta) método. Obtengo mis manipuladores de un contenedor (ya sea de primavera o algo aún más liviano).

La razón de esto es que realmente me gusta la inyección de dependencia, y es difícil lograrlo en Servlets; y realmente no me siento como en casa con la mayoría de los marcos que proporcionan inyección de dependencia de componentes web. Me gusta la simplicidad de los servlets.

Si no fuera por esto, iría con múltiples servlets, aunque hay una compensación; o bien tienes un enorme xml web con muchas (y muchas) asignaciones de servlets o tienes un servlet muy complejo (a menos que uses algo como mi enfoque d-i).