Structure de package pour un projet Java?

116

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

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

java packages

— Mawaldne
source

95

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

— Johnstok
source

2

Je recommande également d'utiliser la mise en page de Maven si vous avez le choix. C'est une structure bien pensée qui a été testée au combat et qui est familière à de nombreux développeurs.

— Dov Wasserman

15

Vous pouvez utiliser cet oneliner pour créer la présentation du répertoire: mkdir -p src / {main / {java, resources, filters, assembly, config, webapp}, test / {java, resources, filters}, site}

— Daniel Hepper

1

La disposition standard du projet de Maven est moche ...: /

— Yousha Aleayoub

2

@YoushaAleayoub tu ne dois pas l'épouser

— Ashvin Sharma

59

Vous pouvez vérifier quelques ressources existantes:

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

Commencez par le domaine inversé, par exemple "com.mycompany".
Utilisez le nom du produit, par exemple «myproduct». Dans certains cas, j'ai tendance à avoir des emballages communs qui n'appartiennent pas à un produit particulier. Celles-ci finiraient par être classées en fonction de la fonctionnalité de ces classes communes, par exemple "io", "util", "ui", etc.
Après cela, il devient plus libre. Habituellement, je groupe en fonction du projet, de la zone de fonctionnalité, du déploiement, etc. Par exemple, je pourrais avoir "project1", "project2", "ui", "client", etc.

Quelques autres points:

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 domaines de fonctionnalité ou d'objectif.
Ne vous souciez pas trop de pousser immédiatement les fonctionnalités communes dans des packages supérieurs. Attendez qu'il y ait un besoin entre les projets, les produits, etc., puis refactorisez.
Surveillez les dépendances inter-packages. Ils ne sont pas tous mauvais, mais cela peut signifier un couplage étroit entre ce qui pourrait être des unités distinctes. Il existe des outils qui peuvent vous aider à en suivre la trace.

— lycono
source

2

Dans le cas du domaine inversé ("com.mycompany"), le package "com" est-il généralement vide à l'exception du sous-package "mycompany"?

— Alex Parker

45

Je suggérerais de créer la structure de votre package par fonctionnalité, et non par couche d'implémentation. Une bonne rédaction à ce sujet est les pratiques Java: Package par fonctionnalité, pas par couche

— analyste de données
source

2

Merci. C'est ce que je cherchais pour transmettre mes pensées à l'équipe

— Pranalee

8

Et si vous souhaitez changer de base de données? Il suffit de chercher dans 30 packages différents. Passer de SFTP aux services Web? Encore une fois, il suffit de chercher dans 30 endroits différents. Certainement pas un fan.

— SamuelKDavis

1

un autre exemple où l'empaquetage par couche a des avantages: si vous sérialisez des classes en JSON (par exemple avec gson), si ces classes sont obscurcies (par exemple par Proguard) la (dé) sérialisation échouera; vous devez configurer Proguard pour ne pas toucher à ces classes - c'est le plus simple de spécifier un seul paquet avec tous

— jmuet

6

J'aime généralement avoir ce qui suit:

bin (binaires)
doc (Documents)
inf (Informations)
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 belle façon d'organiser les choses.

"Ceux-ci peuvent être considérés comme non conventionnels" Ils sont en fait non conventionnels et mauvais au fait ...

— mahieddine

2

@mahieddine Pourquoi les considérez-vous comme mauvaises?

— Thomas Johannesmeyer

Eh bien, ce n'est pas moi qui l'ai dit, mais voici quelques-unes de mes réflexions: Vos classes de test sont du code source donc le répertoire "tst" (la plupart des gens n'abrévient pas test btw) devrait être un sous-répertoire de src (par exemple " src "devient" src / main "et" tst "devient" src / test "). «Inf» semble également inclure du contenu qui pourrait être dans «doc».

— Nico Wawrzyniak le

6

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

— Raj
source

3

La façon dont j'ai habituellement ma hiérarchie de dossiers-

nom du projet
- src
- poubelle
- des tests
- libs
- docs

— pdeva
source

1

Une autre façon consiste à séparer les API, les services et les entités en différents packages.

— Deepak Patankar
source