Discussion :

[elitost]

Bonjour,

Nous réfléchissons actuellement à réunir plusieurs applications web Java en une seule.

Nous sommes en phase de reflexions technologiques, et organisationelle.

Et nous avons quelques différences de points de vue au niveau de l'organisation du projet en terme de découpage des sources.

Je suis partisan du découpage franc en terme d'objectif final des différentes parties, exemple :

- un projet applicatif pour IHM + interactions métiers
- un framework commun (outils, etc)
- un framework données métier
- ...

Pour ma part, les bénéfices sont principalement :
- meilleure compréhension/organisation du code (je ne mets pas les chaussettes et les caleçons dans le même tiroir chez moi, désolé...)
- réutilisabilité
- maintenabilité

Mes contradicteurs préfèrent tout à un endroit, maintenir un seul projet en versionning (VSS avec Java c'est la fiesta), les besoins "actuels" (et dieu sait que les projet informatique ne sont jamais voué au changement) ne nécessitent pas une telle séparation.

Bref, j'aurais voulu avoir vos avis, expériences personnelles sur le sujet :

Séparation franche ? Ou tout en un ?

Merci d'avance pour vos réponses et explications sur cette question.

[millie]

Pour ma part,

On a un ensemble de projet (J2EE, struts) qui repose sur un framework commun (ajoute des couches supplémentaires, permet de gérer les authentifications et d'avoir un découpage commun : on comprend très vite l'organisation de tous les projets de l'entreprise).

A ce que j'ai compris, l'authenfication est notée dans un cookie, ce qui permet de passer d'une application à une autre sans avoir à d'identifier plusieurs fois.

En général, à part le framework, il n'y a aucune base commune entre les applications (il pourrait éventuellement y avoir les objets mappés...)

Les avantages :
- un CVS par projet
- on peut donner des droits à une personne que sur un projet
- on peut répartir les applications sur plusieurs serveurs
- meilleure séparation au niveau des droits (pour les Unit Task)
- quand on redémarrage le serveur, il ne relance qu'un projet
- s'il y a une mise à jour importante du framework, on peut faire la migration de chaque application un par un (voir de garder une ancienne version du framework pendant quelque temps)


Il existe cependant certains codes métiers qui peuvent être commun, mais on utilise en général des procédures stockée ou des programmes cobol pour ça.

A noter que la plupart des applications sont des applications de gestion le framework permet très rapidement (notamment grâce à des générateurs de code) de s'occuper de tâche unitaire classique du type : consultation unitaire, modification unitaire, liste avec datagrid et action unitaire et suppression de masse...

[elitost]

Pour certains "un CVS par projet" est un surplus de travail, ce que je comprends, mais c'est la possibilité comme tu le dis de donner des droits unitairement.

D'autres avis ?

[deltree]

Bonjour,
Le découpage CVS est un chose (faut-il faire confiance à ses voisins ou pas?) le découpage projet en et une autre.
Ici, on est des "extrémiste" du decoupage projet: des projets frameworks "utilititaires", des projets métiers partagé et des projets Web: avec 2 projets par webapp: un pour les servlets, un pour les JSP.

pour ce dernier je trouve ça exagéré, mais la séparation données/IHM est un minimum pour moi, et le découpage en projet permet de garantir cela: les inclusion de projets ne se font que dans un seul sens, et on limite ainsi les interractions.
De même les objets métiers d'applications différentes n'ont ainsi aucune interraction: on limite les impacts et risque de régressions, et donc la couverture de tests de non-régression est moins importante.

[souviron34]

@elitost:

Moi je serais plutôt de ton avis...

En fait j'organise en général les sources dans le style :

• Bibliothèque :
  
  
  
  • communs sans GUI
    
    
    
    • -> maths
    • -> général
    • -> communications
    • -> db (?)
    
    
    
  • interface
    
    
    
    • communs (métier)
      
    • -> répertoire outil1 fenêtres
    • -> répertoire outil2 fenêtres
    • ....
    
    
    
  • ..... (métier1, métier2, ...)
    
    
  
  
  
• Applis
  
  
  
  • Appli1
    
    
  • Appli2
    
    
  • ....
  
  

Avec un cvs global, mais avec bien évidemment la même arborescence...

Arguments : simplicité de compréhension de la structure, donc simplicité de maintenance. Même points communs, divers outils graphiques (logique). D'autre part, entre biblo et applis, c'est le style traditionnel des packages (bin, doc, lib, src) et dans src lib, apps, etc..

[Glob]

Pour certains "un CVS par projet" est un surplus de travail

C'est très relatif. Une fois que tout est en place, tu n'y touches plus à ton CVS.

C'est comme si tu veux changer de souris et que tu exclus les souris sans fil parce qu'il faut changer les piles et que c'est un surplus de travail...