Discussion :

[florianj]

Bonjour,

j'ai 3 modules maven : A,B,C (plus leur parent, D)

A est la partie View de mon appli, B le controller et C le model

A s'adresse à B, qui contrôle la session et les autorisations de l'utilisateur et, si tout ce passe bien, envoie la requête vers C, sinon, génère une exception.

A dépend donc de B, qui lui-même dépend de C.

Or, il semble que A dépendent également de C, par une sorte de cascade de dépendance, ce qui fait que je peux appeler des classes C dans A, ce qui l'encontre de ma structure MVC dans laquelle A ne peut s'adresser à C sans passer par B.

Pour résoudre ce problème, j'ai créer une exclusion de C dans la dépendance vers B du pom.xml de A, comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
<dependency>
        <groupId>project</groupId>
        <artifactId>B</artifactId>
      	<exclusions>
            <exclusion>
                <groupId>project</groupId>
                <artifactId>C</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

Tout va bien, impossible d'utiliser les classes de C dans A. Mais le problème, c'est que du coup, mes requêtes A->B->C ne fonctionnent plus, il semble qu'elles sont stopper dans B.

Quelqu'un aurait une idée pour résoudre ce problème?


Merci !
(J'espère avoir été clair...)

[tchize_]

Je crois que tu confond la logique de ton code (A ne doit pas s'adresser à C) et la logique de dépendance (qui permet à ton application de tourner). Si B s'adresse à C, il est inévitable que C devra se trouver dans l'application finale, et donc A devra inclure C (par le phénomène de dépendance transitive).

Pour la partie A ne s'adresse jamais directement à C, c'est surtout une question d'autocontrole, c'est en dehors du rôle de maven.

[florianj]

(un peu tard, désolé, j'étais sur un autre projet)

Je ne doute pas de ma capacité d'auto-contrôle, là n'est pas le problème, il s'agit plutôt de mettre en place et respecter certaines règles fondamentales qui garantissent la sécurité du projet.

Je trouverai étonnant que maven n'ai pas implémenté un système permettant une séparation stricte des différents modules, même quand ils sont liés par un module tiers. Par exemple, avoir un parent commun ne lie pas les modules ensembles.
Si c'est le cas, ben c'est bien dommage...

[tchize_]

Il est difficile de comprendre exactement ce que tu cherche.

Si j'ai A qui dépend de B qui lui même dépend de C


que j'ai une méthode B qui a grosso modo le code new C();

et que j'appelle cette méthode depuis A. Si maven exclu C et en supposant que le programmeur a bien travaillé (B n'expose pas C à A), je vais avoir un problème à l'exécution. Le code de B renverra un ClassNotFoundException. Or on a besoin d'exécuter B dans les Test de A, sinon A repose sur du vent

Maintenant, en gardant ces emmerdes à l'esprit, il existe dans maven le système d'exclusion. Quand tu met que A dépend de B, tu peux mettre que A dépend de B mais qu'on exclu la dépendance transitive A.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<dependency>
  <groupId>....</groupId>
  <artifactId>B</artifactId>
  <version>....</version>
  <exclusions>
    <exclusion>
      <groupId>....</groupId>
      </artifactId>C</artifactId>
    </exclusion>
   </exclusions>
</dependency>

Mais les exclusions sont en général utilisées quand on dépend d'une librairie trop gourmande et qui a déclaré des dépendances inutiles. Ca permet de corriger le tire après coup.

L'alternative, dans le pom de B, c'est de déclarer la dépendance B => C optionelle. Du coup tout projet dépdendant de B n'aura pas automatiquement la dépendance à C.
Mais de toutes façons, rien n'empechera la programmeur de rajouter A à son pom. Et attention, cette dernière méthode porte bien son nom. Normalement elle s'utilise quand B peux quand même tourner même si C n'est pas disponible.


Ton nerf de la guerre ici, c'est l'exécution et, tu va vite te retrouver emmerdé par tes tests unitaires.


Idéalement, pour les gros truc, la division serait plutot


CApi
Cimpl => CApi
BApi
Bimpl => BApi, Cimpl (scope = test)
A => BApi (du coup a ne voit pas l'implémentation B et par conséquent ne peux même pas savoir qu'elle nécessite C) + Bimpl (scope=test) (du coup B et C deviennent visible uniquement pour les unit test).

et évidement le projet d'intégration
Intégration => Cimpl, Bimpl, A

Avec ca au moins: tu dispose de C pour tes test. Et à la compil seul BApi est visible => aucune classe de C ne peux être utilisée directement par A.
Je ne sais pas si ces propositions répondent à tes questions.

[florianj]

Merci pour tes réponses

Je vais essayer d'expliquer plus à fond mon architecture.

C est un webservice, construit autour d'une database sensible. C reçoit des requêtes et doit les traiter.
B est le module d'entrée du webservice, chargé de contrôler l'identité des utilisateurs, via spring security.
A est une interface graphique.
L'idée, c'est qu'il y aura aussi une communication avec des éléments externes (autre database, autre serviceweb) et qu'il me paraissait judicieux de prévoir un module chargé de la sécurité de l'accès au webservice, que les requêtes proviennent de ma propre interface graphique, ou de services externes.
Quand une requête arrive dans B, B contrôle si l'utilisateur est connecté, et, si c'est le cas, envoie la requête vers C. Or, les classes-fonctions de B et de C ont pratiquement le même nom, histoire de faire plus simple (en soit, les classes de B fonctionnent comme des sortes d'interfaces). Le risque, totalement implicite à la programmation, est d'appeler les classes de C à la place de celles de B, ce qui met en danger tout le programme.

Alors, tu vas me dire, t'as qu'à être attentif, ou nommer tes classes différemment, mais comme il s'agit d'un gros projet sur lequel on risque de se retrouver à plusieurs à travailler, je peux pas me permettre de prendre le risque que quelqu'un d'autre faire le même genre d'erreur et appel une classe DAO depuis l'interface.

DONC, pour résumé, je voudrais que quand j'appel une classe de C dans A, mon IDE me dise qu'il ne trouve pas cette classe, quand bien même il y a accès indirectement via B.

Voilà, j'espère que c'est plus claire comme ça

Si maven exclu C et en supposant que le programmeur a bien travaillé (B n'expose pas C à A)

==> j'ai pas bien compris ce que tu voulais dire par làk mais il y a un peu de ça

Et j'ai pas compris ton explication final : quelle différence entre API-Impl dans le contexte de Maven? Si j'ai bien compris, tes API jouent le rôle d'interface au niveau maven? (désolé si je fais preuve de crétinerie avancée, je suis pas ce qu'on peut appeler un spécialiste de maven)

[tchize_]

je ne comprend pas. Si je suis ta structure, C ne devrait même pas etre dans ton applicaiton C étant un web service, il tourne sur un serveur, et c'est de ce coté là que le check sécurité se fait (via spring security).

Ton application A aura juste besoin d'un client pour ce webservice, (CClient) qui ne dépendra au final que des Socket java (plus soap et une série d'autres trucs bien utiles), mais jamais il ne pourra attaquer le webservice sans passer par le réseau Donc je ne comprend pas comment un programmeur pourrais arriver à contourner la sécurité.

Maintenant, si tu as mis en place la sécurité coté applicatif et que ton webservice est ouvert derrière à tous vents.... Je crois que tu as un plus sérieux problème à prendre en compte que tes programmeurs


Maintenant, d'une manière générale, je verrais ton code comme ceci:

ServiceAApi (je n'ai pas dit webservice) -> fournis des méthodes de data destinées à l'interface (c'est une moitié de ton B actuel)

ServiceAImpl -> implémente ça avec de la sécurité sur un webservice (c'est l'autre moitié de ton B actuel, celle qui fait quelque chose)

ClientInterface -> Dépend de serviceAApi, ne vois que lui et s'en sert pour sa communication. Bien sur, il te faudra un implémentation "mock" pour tester le code. Impossible donc d'accéder à ServiceAImpl et donc au webservice derrière directement. Le compilateur ne les connait pas.Avantage supplémentaire, tu est certain que les développeur ne peuvent jamais attaquer "par erreur" la db , uniquement leur mock local ^^

ClientIntegration -> Dépend de ClientInterface et utilise l'implémentation ServiceAImpl, n'a pas de code et constitue le livrable pour l'utilisateur final.