Discussion :

[joseph_p]

Bonjour

Je me suis récemment lancé dans un petit projet autour de Wicket (partie présentation Web). Je pense utiliser Spring pour la partie métier et l'interfaçage avec la BDD (via Hibernate).

Pour ce faire, je me base sur :
- Spring par la pratique
- divers exemples d'applications Spring

Toutefois, Spring par la pratique a soulevé chez moi de nombreuses interrogations concernant le modèle de mon application. En effet, ils partent d'un besoin "simple" (des "todos" stockés dans des "listes de todos") et pourtant leur modèle est tout en interfaces, managers, objets POJO secondés par des DAO et ainsi de suite. Toutefois, il n'y avait pas dans ce livre de réelles "bonnes pratiques" et ainsi de suite... De même, je n'ai pas trouvé grand chose sur developpez.com ou le net. Or je me souviens d'une application Spring avec un bel "enfer du XML" et j'aimerai éviter de faire ce genre d'erreurs...

Auriez vous des pistes svp ?

Merci d'avance
ZedroS

[fr1man]

J'ai aussi ce bouquin.

Il donne une façon de faire.
Après à toi de voir si elle te convient.
Pour ma part, j'en suis assez satisfait.
Tu obtiens une application bien découpée en couches.
Les DAO pour l'accès aux données, les managers sur lesquels appliquer les strategies de transaction.

Pour ce qui est du xml, je crois que tu peux t'en passer avec les annotations, mais je n'ai pas testé.
Et puis, le fichier de config est assez comprehensible.

[joseph_p]

Merci pour ta réponse.

A propos de la solution des "managers", cela ne fait il pas beaucoup de code pour des fonctionnalités simples ? Notamment au niveau des tests unitaires...

[willoi]

C'est vrai que passe beaucoup de temps avec le xml dans Spring(selon son usage).
En ce qui me concerne j'utilise un framework base sur spring qui a divisé tout en differents services en creant un package par service ainsi qu'un fichier de configuration xml par service.
par exemple : service de persistance, de layout, objets ole, d upload etc...

Du coup, c 'est assez clair et ca te permet de configurer chacun d'entre eux + ou - independement des autres.

[fr1man]

En soit, il n'y a pas grand chose dans un manager.
C'est vrai qu'on peut avoir l'impression d'avoir beaucoup de code pour pas grand chose, mais en fait ça structure bien ton appli.
Quand tu retournes sur un appli ou tout est mélangé, tu te rends compte, de l'utilité de tout ça.

[joseph_p]

Concernant le 1 fichier de contexte par "module", c'est tout à fait pertinent, merci

fr1man : penses tu qu'il est possible de combiner l'idée ci dessus avec celle des managers ? Genre avoir un fichier de contexte par manager.

Ou alors, comme dans Spring par la pratique, tu fais un fichier de contexte par "fonctionnalités", genre un pour hibernate et ainsi de suite ?

D'ailleurs, utilises tu de manière systématique des managers pour tous tes types d'objets ?

Merci d'avance ^^
ZedroS