Quelle est la meilleure façon de partager du code commun (comme des classes de domaine) entre deux ou plusieurs projets ?

Question

Nous développons une application Web composée de deux projets Eclipse. L'un des projets est une application Web basée sur le protocole HTTP. RESTful L'autre projet est un site web. Tous deux seront déployés en tant que WAR. Au départ, ils seront déployés sous la même instance de serveur d'application, mais par la suite, ils seront sur des boîtes séparées.

L'application du site web consomme le RESTful WS app. Il est évident qu'il y aura du code - en particulier des classes de domaine - qui sera commun aux deux projets. Par exemple, il peut y avoir une ressource située dans <app>/users qui expose des opérations CRUD sur des objets User ; pour mettre à jour un utilisateur, l'application du site web POST un objet User à la forme XML dans <app>/users. Une requête GET vers <app>/users/1 renverrait un objet User avec une image XML.

Il est évident qu'avoir une classe Utilisateur dans les deux projets serait assez stupide pour diverses raisons. Je me demande donc quelle est la meilleure façon de procéder ? Mettre le code commun dans un JAR qui est partagé entre les deux projets est ce que j'ai fait dans le passé, mais y a-t-il une meilleure façon ou une façon plus facile ?

Edit : Suppression des références à RESTful. Sémantique mise à part, quelle est la bonne façon de partager du code commun entre deux projets Eclipse ?

Answer 1

Si vous partagez des classes de domaine entre un client et un serveur dans un système RESTful, vous allez à l'encontre de l'objectif de REST. Les contraintes REST sont conçues pour permettre à un système client et à un système serveur d'évoluer indépendamment en veillant à ce que le seul couplage entre les deux systèmes soit limité aux types de médias et aux relations entre les liens.

Si vous avez besoin de partager des objets de domaine, oubliez REST, cela vous causera plus de problèmes que cela n'en vaut la peine.

Answer 2

Il y a plusieurs façons de procéder et, en fonction de votre situation et de vos besoins spécifiques, certaines peuvent s'avérer plus efficaces que d'autres.

dans tous les cas, je recommande vivement l'utilisation d'un système qui comprend les numéros de version.

Une façon classique de le faire serait d'utiliser maven. De plus, il est très bien intégré dans eclipse et vous pouvez structurer vos modules comme faisant partie d'un projet parent, comme par exemple :

project-parent
    project-website1
    project-website2
    project-controllers
    project-model
    [...]

En interne, ces modules peuvent alors dépendre les uns des autres. Vous pouvez aller jusqu'à séparer les interfaces de l'implémentation :

project-parent
    project-website1
    project-website2
    project-api
    project-api-impl
    [...]

et dépendent ensuite du module api la plupart du temps. maven dispose également de quelques mécanismes pour traiter les fichiers WAR.

cette approche (à projet unique) est probablement idéale pour une très petite équipe de développement. le principal inconvénient est qu'il n'est pas pratique de publier les choses séparément - une correction de bogue dans l'implémentation qui n'affecte que le site web 2 nécessiterait également la publication du site web 1.

En outre, la séparation tend à être moins claire dans ce cas, ce qui rend potentiellement trop facile le transfert dans les modules partagés d'éléments qui ne devraient pas vraiment s'y trouver.

un autre modèle serait :

 project1-parent
      project1-webapp
      project1-specifics
      [...]

 project2-parent
      project2-webapp
      project2-specifics
      [...]

 common-parent
      common-api
      common-impl
      common-model
      [...]

Cela rend la séparation un peu plus claire, et vous pouvez publier les choses séparément. également (bien que cela ne soit probablement pas recommandé dans des circonstances normales), project1-webapp pourrait dépendre d'une version plus ancienne ou plus récente du module commun que project2-webapp. maven peut être trouvé ici :

https://maven.apache.org/

un autre ensemble d'outils qui pourrait vous aider à gérer les versions est :

https://gradle.org/

pour en tirer le meilleur parti, vous pouvez également envisager d'utiliser git avec gitflow :

http://git-scm.com/
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/

et comprendre comment l'utiliser pour gérer les versions et les mises à jour.

Personnellement, j'ai trouvé cela TRÈS confus lorsque j'ai commencé - mais cela a beaucoup de sens aujourd'hui.