138 votes

Structure de paquet pour un projet Java ?

Quelle est la meilleure pratique pour mettre en place des structures de paquets dans une application Web Java ?

Comment configurerais-tu tes src, ton code de test unitaire, etc ?

113voto

johnstok Points 16139

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

2 votes

Je recommande également d'utiliser la mise en page de Maven si vous avez le choix. Il s'agit d'une structure bien pensée, qui a fait ses preuves et qui est familière à de nombreux développeurs.

16 votes

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

1 votes

L'agencement standard des projets de Maven est laid... :/

62voto

lycono Points 801

Il existe quelques ressources existantes que vous pouvez consulter :

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

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

  1. Commencez par le domaine inverse, par exemple "com.mycompany".
  2. Utilisez le nom du produit, par exemple "myproduct". Dans certains cas, j'ai tendance à avoir des paquets communs qui n'appartiennent pas à un produit particulier. Ceux-ci finissent 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. En général, je regroupe par projet, domaine de fonctionnalité, déploiement, etc. Par exemple, je peux avoir "project1", "project2", "ui", "client", etc.

Quelques autres points :

  1. Il est assez fréquent, dans les projets sur lesquels j'ai travaillé, que les noms des paquets découlent de la documentation de conception. Habituellement, les produits sont déjà séparés en domaines de fonctionnalité ou d'objectif.
  2. Ne soyez pas trop stressé par l'idée d'intégrer immédiatement des fonctionnalités communes dans des paquets plus importants. Attendez qu'il y ait un besoin à travers les projets, les produits, etc. et refactorez ensuite.
  3. Surveillez les dépendances entre paquets. Elles ne sont pas toutes mauvaises, mais elles peuvent signifier un couplage étroit entre ce qui pourrait être des unités séparées. Il existe des outils qui peuvent vous aider à en assurer le suivi.

3 votes

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

48voto

dataAnalyst Points 251

Je vous suggère de créer la structure de votre paquet par fonction, et non par couche d'implémentation. Un bon article sur ce sujet est Les pratiques de Java : Emballage par fonctionnalité, et non par couche

2 votes

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

9 votes

Et si vous souhaitez changer de base de données ? Il suffit de regarder dans 30 paquets différents. Passer de SFTP à des services Web ? Là encore, vous n'avez qu'à chercher dans 30 endroits différents. Je ne suis vraiment pas fan.

1 votes

Un autre exemple où le packaging par couche présente des avantages : si vous sérialisez des classes en JSON (par exemple avec gson), si ces classes sont obfusquées (par exemple par Proguard), la (dé)sérialisation échouera ; vous devez configurer Proguard pour qu'il ne touche pas à ces classes - le plus simple est de spécifier un seul package avec toutes les classes.

3voto

Gadget Points 78

Ici vous pouvez lire des informations sur la disposition standard des répertoires et sur la structure des répertoires et des paquets pour un projet Java.

2voto

Space cowboy Points 71

Un autre très bon article sur la structure des paquets Java : Gestion du chemin de classe Java

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X