Nous construisons une petite application en utilisant différentes couches architecturales telles que le domaine, l'interface, l'infrastructure et l'application. Cela suit le modèle Onion DDD. Je me demande maintenant s'il y a un avantage à diviser l'application en un projet maven multimodule. Pour autant que je puisse voir maintenant, cela semble rendre les choses plus difficiles que nécessaire. L'application entière sera déployée sous la forme d'un seul fichier WAR dans un conteneur Tomcat.
Réponses
Trop de publicités?Le fractionnement de votre application est utile pour les raisons suivantes :
-
Lorsqu'une certaine partie du projet nécessite une nouvelle fonctionnalité ou la correction d'un bogue, vous pouvez simplement vous concentrer sur ce module et n'exécuter que les tests le concernant. La compilation d'une fraction de l'ensemble du code et l'exécution des seuls tests correspondants accélèrent votre travail.
-
Vous pouvez réutiliser le code des modules dans différents projets. Supposons que votre projet contienne un code générique bien écrit pour l'envoi de courrier. Si, par la suite, vous avez un autre projet qui nécessite une fonctionnalité d'envoi de courrier, vous pouvez simplement réutiliser votre module existant ou le développer (dans un autre module en l'ajoutant comme dépendance).
-
Une maintenabilité plus facile sur le long terme. Peut-être qu'aujourd'hui, cela semble être un petit projet. Dans quelques mois, les choses seront peut-être différentes et vous devrez alors procéder à un remaniement supplémentaire pour diviser les choses en unités logiques (modules).
-
Clarté conceptuelle (ajoutée par Adriaan Koster).
Concernant le WAR : Vous pouvez avoir un module d'assemblage qui rassemble les choses et produit un fichier WAR final à partir de tous les modules connexes.
Au départ, cela peut sembler un surcroît de travail, mais à long terme, les projets modularisés sont plus faciles à travailler et à maintenir. La plupart des développeurs sains d'esprit préfèrent cette approche.
L'utilisation de plusieurs modules vous oblige à avoir une hiérarchie de dépendances. Vous avez un module qui est autonome et qui ne dépend d'aucun autre de vos modules. Vous en avez un autre qui ne dépend que de celui-ci. Cela peut sembler plus difficile que de permettre à n'importe quoi de dépendre de n'importe quoi d'autre, mais cette approche aboutit à un fouillis de dépendances qu'il est difficile de corriger par la suite.
Si vous essayez de suivre un modèle en couches, je vous suggère de placer chaque couche dans un module différent. Cela vous permettra de ne pas être tenté de casser le modèle.
Pour autant que je sache, Maven n'aide guère pour les dépendances WAR. Comme vous parlez d'un seul WAR, cela ne devrait pas poser de problème.
Vous pouvez séparer les classes java en plusieurs sous-modules "jar", mais si vous divisez le projet WAR en plusieurs WAR plus petits, en utilisant une sorte de packaging "superposé", les choses se compliquent.
A titre d'information, un de nos projets contient trop de pages web, nous avons donc décidé de le diviser en plusieurs sous-modules WAR, cependant, la session n'est pas partagée entre les différents WARs déployés, et nous n'allons pas utiliser de Kerberos. Enfin, nous avons modifié de nombreuses sources de Glassfish, Jetty, MyFaces, etc. pour qu'elles résolvent les données web.xml dans les JARs. Et nous avons converti l'ensemble du projet à Facelets 2.0 (pour éviter la dépendance de JDK tools.jar et du gestionnaire de ressources personnalisé), la seule raison étant de changer les sous-modules WAR en sous-modules JAR, et de déplacer toutes les applications web/pages dans des ressources de classe. En conclusion, Maven fait un excellent travail pour les dépendances JAR, mais pas de WAR ou de WAR unique.
EDIT Vous pouvez mettre applicationContext.xml
dans un des sous-modules de base, et l'importer par classpath:com/example/applicationContext.xml
. De plus, Spring 3.0 supporte les annotations, vous pouvez faire en sorte que Spring les analyse automatiquement au lieu de les déclarer toutes dans le xml.
Diviser votre projet en plusieurs projets maven est utile si vous voulez réutiliser vos classes dans un autre projet ou si vos projets sont déployés dans des configurations différentes.
Pensez peut-être à un webservice - si vous hébergez le serveur, vous pourriez construire un projet pour vos classes de domaine (modèles) et vos interfaces de point de terminaison qui pourraient être utilisées par le serveur et le client. Le serveur serait un autre projet construit dans un WAR.
Pour développer d'autres clients, le premier projet pourrait également être utilisé.
Utilisez un projet parent pour la gestion des dépendances sur les projets communs (comme la journalisation) et les différents profils et configurations de construction.