Question

Je commence un nouveau projet Web Java qui utilise Hibernate et une architecture MVC standard. Je viens tout juste de commencer à mettre en place la structure des projets et ce faisant, j'ai commencé à regarder autour de moi pour voir s'il existait des normes dans ce domaine, à savoir où les contrôleurs devraient aller et, en général, le meilleur moyen de tout organiser. Cependant, je n'ai pas vraiment trouvé de directives.

Donc, ce que je suis curieux de savoir, c'est

  • Quelqu'un a-t-il connaissance des règles de bonne pratique relatives à la présentation d'un projet Web Java?
  • Quelqu'un at-il un ensemble particulier de règles strictes qu'il respecte toujours pour différents types de projets?
  • Les gens ont-ils tendance à diviser les packages en plusieurs couches, telles que présentation, entreprise et application?
Était-ce utile?

La solution

Pour continuer ma réponse précédente, j'ai de nombreux projets Web. Dans tous, la structure sous src est plus ou moins la même. Les packages sont séparés grossièrement en 3 couches logiques.

Tout d'abord, comme vous l'avez dit, se trouve la couche de présentation pour les servlets, les écouteurs d'applications et les assistants.

Deuxièmement, il existe une couche pour la couche d'accès hibernate modèle / base de données. La troisième couche pour la logique métier. Cependant, parfois, la frontière entre ces couches n'est pas claire. Si vous utilisez hibernate pour l'accès à la base de données, le modèle est défini par les classes hibernate. Je les mets donc dans la même zone que les objets dao. Par exemple. com.sample.model contient les objets de données en veille prolongée et com.sample.model.dao contient les objets dao.

Si vous utilisez straight jdbc (généralement avec Spring), je trouve parfois plus pratique de rapprocher les objets de données de la couche de logique applicative plutôt que de la couche d'accès à la base de données.

(Le reste de la matière tombe généralement dans la couche de gestion).

Autres conseils

Cela dépend vraiment de votre infrastructure Web.

Par exemple, si vous utilisez Wicket, les fichiers java et les pages Web coexistent dans le même répertoire dans la plupart des autres frameworks, pages (fichiers .jsp ou quel que soit votre moteur de présentation) et Les éléments code-behind (fichiers java) sont complètement séparés.

Lisez donc la documentation fournie avec votre infrastructure (Spring MVC, Struts, JSF e.t.c).

Une autre bonne proposition consiste à utiliser les archétypes Maven pour générer un squelette pour votre infrastructure spécifique. Certains frameworks Web (tels que Seam) ont même leur propre outil de génération de code qui jette les bases de votre projet Web.

Ma seule bonne suggestion (qui n'est pas mentionnée par Yoni) pour le répertoire src est faire des paquets en fonction du but de l'entreprise et NON en fonction du type / couche

Cela signifie que les packages pour

  • com.mycompany.myproject.customers
  • com.mycompany.myproject.departments
  • com.mycompany.myproject.billing
  • com.mycompany.myproject.reports
  • com.mycompany.myproject.admin

et NON

  • com.mycompany.myproject.entities
  • com.mycompany.myproject.tables
  • com.mycompany.myproject.graphs
  • com.mycompany.myproject.dialogs
  • com.mycompany.myproject.servlets

La deuxième structure est trop générique, a tendance à se résoudre en gros paquets avec des trucs sans rapport et est difficile à maintenir.

Tout d’abord, suivre la structure conventionnelle d’une idée populaire, comme Eclipse, Netbeans, etc. Dans Eclipse, par exemple, tout est déjà organisé avec les dossiers WEB-INF et META-INF, ce qui facilite l'emballage et le déploiement. Le code source des classes (généralement sous src) est automatiquement copié dans WEB-INF / classes. Il y a quelques autres considérations:

  1. Si vous utilisez MVC, il est possible que vous n’ayez pas besoin d’accéder directement à vos fichiers JSP. Si tel est le cas, conservez le code source de JSP sous WEB-INF / jsp, pour des raisons de sécurité.
  2. De même, conservez les fichiers de balises personnalisés sous WEB-INF / balises.
  3. Conservez les fichiers javascript dans le dossier js, les fichiers css dans le dossier style, etc. Tous les dossiers doivent être au même niveau que WEB-INF pour imiter un déploiement réel.
  4. Il est bon de séparer votre code en packages en fonction des couches. Il est évident que vos daos Hibernate n'ont pas besoin d'être dans le même package que vos servlets.
  5. Si vous vous retrouvez avec trop de servlets dans le même package, envisagez de les sous-conditionner en fonction de leurs fonctionnalités, mais il est intéressant de noter qu'ils ont un package ancêtre commun - cela facilite la lisibilité.

Utilisez la mise en page d'archétype Maven pour les applications Web.

project
|-- pom.xml
`-- src
    `-- main
        |-- java
        `-- webapp
            |-- WEB-INF
            |   `-- web.xml
            `-- index.jsp

J'ai inclus le dossier java dans l'exemple ci-dessous. Peut-être que c'était évident, mais il a été laissé de côté dans le lien ci-dessus pour une raison quelconque.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top