Discussion :

[ziller]

bonjour,

je suis en train d'explorer l'annotation @Configurable dans Spring 2.0
pour le cas d'utilisation suivant :

* j'ai deux beans Personnel et Enfant
* je souhaiterai pouvoir, connaissant un Personnel, accédez à une
liste des beans Enfant qui lui sont liés
* l'aspect @Configurable m'offre cette possibilité en injectant
dynamiquement EnfantDAO dans le bean Personnel

Y-a-t-il des contre indications à cette interconnexion entre le bean
Personnel et le DAO d'Enfant ?
en tous les cas, à l'usage je trouve cela particulièrement utile et
prometteur.

Par contre, cela impacte-t-il les performances, sachant que
l'application sur laquelle je souhaite utiliser ce principe contient
une centaine de beans?

merci pour vos conseils

[ego]

Poses toi la question : Comment aurais-je fait si je n'avais pas eu Spring ?
Tu trouveras par toi même la réponse à ta question sur les perfs.

[ziller]

oui, je vois bien l'incidence que cela aura sur le design de l'application, à savoir que des pojo de la couche domaine vont s'enrichir de liens vers d'autres pojos grâce à l'injection des DAO

par exemple, dans un controler qui doit fournir à une vue le détail d'une personne avec la liste de ses enfants, je n'aurai besoin de la couche service que pour me fournir la personne connaissant son numéro. Plus besoin d'injection dans mon controler du service qui me fournit la liste des enfants.

j'ai l'impression que ca permet d'avoir un domaine plus riche et que ca simplifie le développement.

maintenant comme c'est ma première appli Spring je dois dire que les conséquences sur les perfs m'échappent un peu, en particulier :

* surcout lié à l'utilisation d'AspectJ
* surcout mémoire liée à l'injection des DAO dans chaque POJO du domaine

au déla des performances, certains effets de bord de cette pratique sont-ils rédhibitoires?
plus de sérialisation possible des beans du domaine par exemple? Difficulté à mettre en oeuvre les test unitaires? autre chose?

cordialement

[ego]

Mais en fait, si tu utilises Hibernate tu n'auras pas besoin de faire connaitre les DAO à tes objets du domaine. Tes objets du domaine sont donc encore plus propres.

[ego]

Pour compléter ma précédente réponse.

- Surcoût d'AspectJ : ça dépend des aspects et des pointcuts. Dans pas mal de cas ton code est directement modifié pa rle compilateur aspectj donc aucun surcoût par rapport à une écriture similaire à la main.

- Injection des DAO dans les objets du domaine. Là tu ne va pas y arriver car tes objets du domaine sont les objets qui ne sont pas sous contrôle de Spring. Ils sont en effet créés par tes DAO via les requêtes en base et non créés par la factory Spring. C'est d'ailleurs dans ce cas que l'utilisation d'AspectJ devient nécessaire.

- Pour la Serialization, tu as raison. Et c'est pourquoi je t'ai parlé d'Hibernate. Tes objets restent totalement ignorants de l'existance d'une base de données. Maintenant, avec le lazy-loading d'Hibernate j'ai eu des "soucis" de sécurité dans le cas d'applications distribuées avec JavaWebStart (problématiques liées à CGLIB) mais dans le cas d'une application Web classique, pas de soucis.

[ziller]

bonjour,

merci pour tes commentaires, voici quelques précisions

- Injection des DAO dans les objets du domaine. Là tu ne va pas y arriver car tes objets du domaine sont les objets qui ne sont pas sous contrôle de Spring. Ils sont en effet créés par tes DAO via les requêtes en base et non créés par la factory Spring. C'est d'ailleurs dans ce cas que l'utilisation d'AspectJ devient nécessaire.

oui c'est bien avec AspectJ et l'annotation @configurable que j'y suis arrivé : ca fonctionne très bien. Les objets ne sont pas instanciés par Spring mais la dépendance Spring que j'ai définie est quand même réalisée
on m'a dit par ailleurs qu'on pouvait réaliser la même chose sans AspectJ, je creuse cette option...

- Pour la Serialization, tu as raison. Et c'est pourquoi je t'ai parlé d'Hibernate. Tes objets restent totalement ignorants de l'existance d'une base de données. Maintenant, avec le lazy-loading d'Hibernate j'ai eu des "soucis" de sécurité dans le cas d'applications distribuées avec JavaWebStart (problématiques liées à CGLIB) mais dans le cas d'une application Web classique, pas de soucis.

non j'utilise IBatis. En fait je me méfie un peu du lazy-loading plus pour des aspects de performances...

a+