Une ou plusieurs servlets par webapp?

Question

Je sais, cela dépend de la webapp. Mais dans le cas normal, que faites-vous: une servlet, qui sert différentes pages (comme une application autonome avec un contenu changeant) ou pour chaque page une seule servlet.

Prenez par exemple un blog. Il y a la page d'accueil avec les entrées de blog les plus récentes, une vue d'article pour afficher une entrée de blog et une archive. Implémentez-vous cela avec trois servlets différents, ou un qui est envoyé aux fonctions. Au moins une bonne partie du contenu est partagée, comme les en-têtes http. Alors, quelles sont vos expériences, qu'est-ce qui fonctionne le mieux?

Answer 1

Habituellement, vous allez créer une servlet par cas d'utilisation. Les servlets agissent comme des contrôleurs pour votre application. Lorsque vous identifiez une interaction d'un utilisateur, implémentez une servlet pour contrôler cette interaction. C'est-à-dire, si vous utilisez une servlet/JSP simple pour construire le site. Si vous utilisez un framework tel que struts, vous constaterez qu'ils implémentent le pattern de contrôleur frontal et utilisent une seule servlet qui reçoit toutes les requêtes et les transmet à des classes d'action implémentant la logique de la requête de l'utilisateur. C'est beaucoup plus difficile à faire soi-même mais c'est une bonne pratique ... c'est la raison pour laquelle tant de gens utilisent ces frameworks. Donc, la réponse courte est, vous allez créer beaucoup de servlets par webapp, car chaque application web exposera plusieurs cas d'utilisation.

[EDIT] Relisant votre question il semble que vous utilisiez le terme site pour signifier page ou vue. Encore une fois, cela dépend de ce qui se passe sur cette vue. Par exemple, pour afficher la dernière entrée de blog, vous pouvez avoir une servlet qui construit la liste des entrées de la base de données pour l'affichage. Si l'utilisateur clique sur une entrée, une autre servlet peut récupérer cette entrée unique pour la visualisation, etc. Principalement, chaque action est un cas d'utilisation donc une servlet différente.

Answer 2

La plupart des frameworks Web utilisent un servlet répartiteur (ex: Spring MVC) qui prend en charge les requêtes de routage vers les classes/contrôleurs appropriés. Lorsque vous commencez à avoir beaucoup de pages, cette approche fonctionne mieux parce que vous avez un moyen plus convivial (en ce qui concerne web.xml) de déclarer/gérer une classe qui gère les requêtes http et son URL. Exemple (ressort mvc à nouveau):

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

En outre, ayant une servlet Dispatcher conserve votre flux de code centralisé.

Answer 3

Cela dépend.

Dans mes derniers projets, j'ai implémenté une seule servlet qui délègue à plusieurs objets de type servlet qui sont instanciés en mode injection de dépendance. Par exemple, j'ai quelque chose comme ça dans mon servlet (pseudo-code): Méthode

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

où Handler est une interface avec une poignée booléenne (requête, réponse). J'obtiens mes gestionnaires d'un conteneur (que ce soit Spring ou quelque chose d'encore plus léger).

La raison de ceci est que j'aime vraiment l'injection de dépendance, et il est difficile de l'obtenir dans les servlets; et je ne me sens vraiment pas à la maison avec la plupart des frameworks qui fournissent une injection de dépendances de composants Web. J'aime la simplicité des servlets.

N'étaient pas pour cela, j'irais avec plusieurs servlets, bien qu'il y ait un compromis; soit vous avez un énorme xml web avec beaucoup (et beaucoup) de mappages de servlet ou vous avez une servlet très complexe (sauf si vous utilisez quelque chose comme mon approche d-i).