web-dev-qa-db-fra.com

Structure de package pour un projet Java?

Quelle est la meilleure pratique pour configurer des structures de package dans une application Web Java?

Comment configureriez-vous votre code src, code de test unitaire, etc.?

javapackages
98
mawaldne

Vous pouvez suivre la disposition de projet standard de maven . Vous n'êtes pas obligé d'utiliser réellement maven, mais cela faciliterait la transition à l'avenir (si nécessaire). De plus, les autres développeurs seront habitués à voir cette mise en page, car de nombreux projets open source sont ainsi disposés

76
johnstok

Vous pouvez vérifier quelques ressources existantes:

  1. Emballez correctement vos classes Java
  2. Spring 2.5 Architecture
  3. Tutoriel Java - Nommer un paquet
  4. Conventions d'appellation Sun

Pour ce que cela vaut, mes directives personnelles que j'ai tendance à utiliser sont les suivantes:

  1. Commencez avec le domaine inverse, par exemple. "com.mycompany".
  2. Utilisez le nom du produit, par exemple "mon produit". Dans certains cas, j'ai tendance à avoir des paquets communs qui n'appartiennent pas à un produit particulier. Ceux-ci finiraient par être classés en fonction de la fonctionnalité de ces classes communes, par exemple. "io", "util", "ui", etc.
  3. Après cela, il devient plus libre. Généralement, je groupe en fonction du projet, de la fonctionnalité, du déploiement, etc. Par exemple, je pourrais avoir "projet1", "projet2", "ui", "client", etc.

Quelques autres points:

  1. Il est assez courant dans les projets sur lesquels j'ai travaillé que les noms de paquet découlent de la documentation de conception. Habituellement, les produits sont déjà séparés en zones de fonctionnalité ou d’utilité.
  2. Ne vous contentez pas d'insérer immédiatement des fonctionnalités communes dans des packages plus élevés. Attendez qu'il y ait un besoin pour tous les projets, produits, etc., puis effectuez une refactorisation.
  3. Observez les dépendances entre paquets. Ils ne sont pas tous mauvais, mais cela peut signifier un couplage étroit entre ce qui pourrait être des unités séparées. Il existe des outils qui peuvent vous aider à garder une trace de cela.
53
lycono

Je suggèrerais de créer la structure de votre paquet par caractéristique et non par couche d’implémentation. Une bonne rédaction à ce sujet est Les pratiques Java: Package par fonctionnalité, pas par couche

39
dataAnalyst

J'aime généralement avoir les éléments suivants:

  • bin (binaires)
  • doc (Documents)
  • inf (Information)
  • lib (Bibliothèques)
  • res (ressources)
  • src (Source)
  • tst (test)

Celles-ci peuvent être considérées comme non conventionnelles, mais je trouve que c'est une très bonne façon d'organiser les choses.

4
user5425586

La façon dont j'ai généralement ma hiérarchie de dossier-

  • Nom du projet
    • src
    • poubelle
    • tests
    • libs 
    • docs
1
pdeva
The way I usually organise is
- src
        - main
                - Java
                - groovy
                - resources
        - test
                - Java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc
0
Raj