Structure de dossier d'application Web Java

En tant que débutant à J2EE, j'ai récemment commencé à développer mon propre projet à partir de zéro en utilisant le noyau de J2EE: Servlets & Jsps.

Je n'ai pas pu évaluer si la structure de mon dossier de projet est correcte ou non. Voici la structure de mon dossier de projet.

Avant de poser une question, j'avoue que je n'ai pas pu répondre ni justifier si quelqu'un me demande pourquoi ce type de structure de dossiers. La question: est-ce un bon signe de mettre mon jsps en dehors du web-inf. Sinon, pourquoi en est-il ainsi? Si oui pourquoi?

Existe-t-il une convention de structure de dossier standard pour une application Web J2EE, je sais que maven a mis en place certaines normes, mais nous pouvons toujours personnaliser selon les exigences, je crois.

J'ai fait un peu de recherche sur Google et j'ai trouvé les deux références 1 2

où dans les réponses ne sont pas sur la même page, dont je ne pouvais tirer aucune conclusion.

Quels sont les points à considérer lors de la mise en place de la structure de dossiers pour une application Web J2EE, surtout où les Jsps, le contenu statique doivent-ils entrer et pourquoi?

La structure standard d'un fichier WAR est la suivante:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

Maven génère cela pour vous en utilisant votre src / main / java, ressources, webapp et vos dépendances (en les plaçant dans / lib) dans le plugin maven-webapp , mais c'est la mise en œuvre. La chose importante à réaliser est que tout ce que vous mettez dans WEB-INF n'est pas accessible de l'extérieur , alors que tout dans le répertoire racine de WAR est public.

En général, vous ne voulez pas mettre beaucoup de choses à la racine, car vous voulez que votre application gère tous les accès à l'aide des servlets et des filtres que vous définissez dans web.xml. Il est courant de voir un index.html (ou .jsp) à la racine qui redirige vers un servlet, par exemple une action Struts .

Les implémentations MVC typiques telles que Stripes ou Struts déconseillent aux utilisateurs d'accéder directement aux JSP, préférant que les JSP soient en lecture seule. Ils recommandent de créer des contrôleurs qui transmettent aux JSP après le traitement de la demande, et les JSP rendent simplement le résultat. Par exemple, la soumission d'un formulaire à /loginexécutera une action qui traite la demande de connexion, crée la session de l'utilisateur et transfère l'utilisateur vers la vue de connexion de la page d'accueil JSP.

La réponse habituelle à "quelle est la bonne façon?" ou "est-ce la bonne façon?" est ..... cela dépend .

Tout ce que je peux faire, c'est vous dire les avantages et les inconvénients d'idées spécifiques. Ce qui suit est à 100% mon avis. Je ne connais pas d'exigences ou de règles spécifiques. Je suis sûr que quelqu'un sera en désaccord avec moi.

JSP

Essayons de mettre ou non les JSP dans WEB-INF.

Avantages de mettre des JSP dans WEB-INF:

• Vous contrôlez la façon dont les JSP sont exécutés. Si vous voulez qu'un JSP soit paramétré et réutilisable (ce qui est vraiment difficile avec un JSP de toute façon), vous pouvez les mettre dans WEB-INF et utiliser un servlet ou un contrôleur d'action Struts ou un autre contrôleur frontal pour effectuer le pré-traitement puis passer le contrôle à la JSP, en passant dans le bon environnement (comme les attributs de requête, les contrôles de sécurité, l'assainissement des paramètres, etc.)
• Vous pouvez par programme ou même au niveau d'un pare-feu ou d'un niveau IDS bloquer les requêtes HTTP vers * .jsp pour réduire la probabilité que quelqu'un télécharge un JSP vers la racine Web et puisse ensuite exécuter du code en tant que serveur Web. Ils devraient écraser un JSP existant. Pas un énorme gain de sécurité, mais cela rend le compromis un peu plus difficile.
• Applique de bonnes habitudes, comme MVC, contrôleur frontal, filtres de servlet, injection de dépendances, etc. par opposition à un grand JSP monstrueux qui fait tout le travail lui-même et est difficile à lire / à entretenir.

Inconvénients de mettre des JSP dans WEB-INF:

• Vous ne pouvez pas accéder directement à la page, même s'il s'agit d'une simple page autonome qui ne nécessite aucun traitement initial. En effet, les fichiers sous / WEB-INF ne sont pas gérables par un conteneur de servlet.

Fichiers statiques

En termes de fichiers purement statiques comme HTML, image, feuille de style, javascript, etc. mettez ceux-ci sous la racine web (my_app dans votre cas), mais PAS / WEB-INF (car il n'est pas accessible).

Disposition générale

Quant à la disposition générale du répertoire, elle dépend quelque peu de votre processus de construction. J'aime tout stocker sous "src" ou "source" car cela indique clairement quels fichiers sont générés par la construction et quels sont les fichiers source purs. mainvous permet de séparer le code de test comme les classes junit de votre code source principal, ce qui est bien aussi. Mais si vous n'avez pas de tests unitaires (oh non!), Alors c'est une distinction dénuée de sens.

D'un autre côté, si vous ne manipulez pas du tout la racine Web pendant la construction (comme s'il s'agit uniquement de fichiers JSP et statiques), alors peut-être que vous la gardez au niveau supérieur, comme /webrootou /deployet copiez des fichiers si nécessaire, tels que Fichiers .class ou .jar. C'est une habitude des êtres humains (en particulier des développeurs) de trop organiser. Un bon signe de surorganisation est d'avoir de nombreux dossiers avec un seul sous-dossier.

Ce que vous avez montré

Vous avez indiqué que vous suiviez une convention établie par maven, donc si vous utilisez déjà maven, respectez simplement cette disposition. Il n'y a absolument rien de mal avec la disposition que vous avez décrite.

Eh bien, votre src / main / webapp me rappelle sûrement un projet maven. Ce qui est bon.

Pour le my_app / jsps, je ne suis pas sûr cependant. Les développeurs laissent généralement leur jsp dans le dossier webapp, ou si vous voulez faire un peu de mappage d'url, dans un répertoire webapp / jsp.

!Avertissement! : Vous ne devez jamais mettre un fichier jsp dans web-inf. Votre WEB-INF ne doit contenir que des fichiers xml pour configurer votre site Web. N'oubliez pas que votre jsp est une page Web ou une partie d'une page Web.

Vous pouvez utiliser le nom des dossiers comme modèle, partiel ... tout ce qui vous convient. Il devrait être facile à trouver pour un étranger. Séparez simplement différents types de contenu comme les pages complètes, les modèles, les vues partielles ...

Je suis d'accord avec Brice . Je suis aussi débutant en J2EE, mais je pense qu'il vaut mieux travailler facilement et clairement au début.

Le dossier racine est WEBAPP, et vous devriez faire en sorte que votre structure Web pense que la plupart des pages s'y trouveront. Sinon, lorsque les pages communiquent entre elles, vous ne pouvez probablement pas gérer les relations de fichiers sans erreurs.

En fait, l'application WAR peut être construite sans WEB-INF/web.xml. Il est possible de faire une application WAR avec uniquement des classes Java à l'intérieur.

Source: éléments du descripteur de déploiement web.xml

Avec les annotations Java EE, le descripteur de déploiement web.xml standard est facultatif. Selon la spécification du servlet 3.0 sur http://jcp.org/en/jsr/detail?id=315 , des annotations peuvent être définies sur certains composants Web, tels que les servlets, les filtres, les écouteurs et les gestionnaires de balises.

Donc, de nos jours, il est possible de construire WAR qui ressemble à JAR avec des .warextensions :)

Pour répondre à votre question, la structure de WAR dépend de vos besoins.

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)