2010-05-07 16 views
1

Je voudrais savoir comment vous configurez vos projets en Java. Par exemple, dans mon projet de travail actuel, une application J2EE vieille de six ans avec environ 2 millions de LoC, nous n'avons qu'un seul projet dans Eclipse. La structure du package est divisée en niveaux, puis domaines, donc il suit guidelines from Sun/Oracle. Un énorme ant-script construit des bocaux différents à partir de celui-ci.Comment structurer des applications en plusieurs projets et comment nommer les paquets en Java?

Personnellement, je pense qu'il serait préférable d'avoir plusieurs projets, au moins pour chaque niveau. Récemment, je jouais avec une structure de projet comme celui-ci:

  • Domainproject (ne contient que POJO annotés, nécessaires à tous les autres projets)
  • dataLayer (seulement la persistance)
  • BusinessLogic (services)
  • Présentateur
  • Voir

de cette façon, il devrait être plus facile d'échanger des composants. De plus, lorsque j'utilise un outil de construction comme Maven, je peux tout avoir dans un dépôt, alors quand je ne travaille que sur le frontend, je peux obtenir le reste comme une dépendance dans mon classpath.

Est-ce que cela a du sens pour vous? Utilisez-vous différentes approches et à quoi ressemblent-elles?

En outre, j'ai du mal à nommer correctement mes paquets/projets. À l'heure actuelle, la structure du projet ci-dessus reflète dans les noms des paquets, par exemple. de.myapp.view et il continue avec certains sous-dossiers techniques comme interne ou interfaces. Ce qui me manque ici, et je ne sais pas comment le faire correctement, c'est la distinction à un certain domaine. Lorsque le projet s'agrandit, il serait bon de reconnaître un domaine particulier, mais aussi les détails techniques pour naviguer plus facilement dans le projet.

Ceci conduit à ma deuxième question: comment nommez-vous vos projets et paquets?

Répondre

2

Votre approche est logique. Je me décomposerais normalement en un modèle (partagé), de nombreuses bibliothèques, puis les applications consommant ce code et les interfaces graphiques - tous en tant que projets séparés. J'ai tendance à suivre le dicton des programmeurs pragmatiques de construire des ensembles d'outils, pas des applications. De cette façon, vous pouvez réassembler vos composants de différentes façons. Chaque bibliothèque/application serait son propre projet, avec des tests unitaires/fonctionnels et un livrable (dans votre cas, un artefact Maven que vous pouvez stocker et mettre à jour de manière appropriée).

Le seul problème est de gérer les interfaces et les liens entre ces composants. Un environnement de test d'intégration efficace est la clé ici.

1

Cela conduit à ma deuxième question: comment -vous vos nommer projets et paquets?

Pour les noms de projet, je préfère un nom interne comme Longhorn = WinVista. Ce nom ne change jamais (comme les noms de mes enfants).Ainsi, le marketing, etc peuvent enregistrer n'importe quel nom, rebrand, etc

Les paquets sont une question de préférences et de style (personnel). Et normalement le programmeur senior décide de la structure. Bien sûr il y a des "standards" comme "gui" pour les classes UI, "util", "misc", "impl" pour les implémentations d'interface, "domaine" pour les classes d'objets de domaine, etc.