new Blog( perso );

Lors de la conférence sur l'utilisation avancée de l'AOP avec AspectJ, Chris Richardon (Mr POJO) s'est permi une question provocatrive : "un POJO avec des annotations est-il toujours un POJO ?". C'est vrai qu'un objet métier "POJO" avec des annotations Hibernate, Acegy-security et Spring n'a plus vraiment l'air "Plain Old Java" !

La réponse courte : Un POJO annoté "@Entity" signale juste ce qu'il est, pas ce qu'on doit faire avec, c'est donc tout à fait acceptable (comme @Sensible pour la classe Document par exemple).

Par contre, une annotation du type @Tracable montre ce que la classe attend, à savoir d'être logguée par un framework externe, même s'il n'est pas explicitement défini. Cela crée donc un couplage indirect qui est contraire à l'esprit POJO.

J'en ai profité pour lui poser quelques questions sur son mini-framework "arid". Celui-ci permet de définir les méthodes de recherche hibernate du genre "findByNameOrderByAge" dans une interface Dao, l'implémentation étant produite à la volée par analyse du nom de la méthode, comme c'est le cas avec Ruby-on-rails ou Grails.
D'après mes mesures sur un projet réel, 90% des "finders" Hibernate sont de type findById ou findBy. Cela pourrait donc être un réel gain de productivité.

Après le fichier XML en pagaille, on voit fleurir le annotation à tout faire. ApectJ, Hibernate, JPA, Spring, EJB3, ... n'en jettez plus !

Le code source risque de devenir rapidement un foutoir d'annotations. Pourtant il est vrai qu'il est plus naturel de déclaré qu'une référence à la datasource est @Autowired (injectée automatiquement par Spring) que d'aller chercher le bon fichier XML pour l'éditer...

Il faudra apprendre a trouver le juste équilibre. Lors de la conférence sur JPA (persistence des données) le présentateur à clairement différencié les méta-données modèle (tel attribut est la clé primaire, tel autre une FK) qu'il aime déclarer comme annotations et les méta-données de persistance (tel attribut correspond à telle colonne en base) qu'il préfère laisser dans le XML, ne serait-ce que pour se laisser la liberté d'avoir plusieurs bases pour un même modèle.