Conception d'une couche applicative Spring

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

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.

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...

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.

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.

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

Tu peux créer autant de fichiers de config que tu veux.
Sur une petite application, un seul fichier peut suffire.
Sur des applications pour grandes, j'en fais un pour mes managers, un pour mes daos.
Il n'y a pas grand chose à définir pour un manager, à part les transactions, car j'utilise la propriété autowire.

J'utilise des managers pour ma couche de services, qui manipulent mes daos.
C'est sur ces managers, que je vais appliquer mes transactions.

Bonjour,

Mes managers me servent à la fois pour l'application des règles métiers et gérer la sauvegarde par transaction...

Mettre tout le code métier directement dans les managers n'est il pas problématique ?

En effet, autant les couches d'accès sont bien découpés, autant là pour tout le code métier c'est un peu la jungle à priori...

Perso j'avais vu une application découpée ainsi :
- Business Objects
- Services

Le but étant de découpler les différentes choses. Là par exemple ça ferait quelque chose comme :
- Managers -> couche haute de l'accès aux données (par domaine)
- Services -> code métier

Qu'en dites vous ?

Merci d'avance :oops:
++
ZedroS

J'ai une couche de Daos, pour l'accès aux données, et une couche service (managers) pour la logique métier.

Très bien, encore merci :)