Scolaire

L'autre jour, je discutais persistance avec mes collègues, je leur recommandais l'utilisation d' Hibernate avec les annotations en lieu et place des fichiers de mapping XML pour plusieurs raisons :

-        Lorsque l'on rajoute ou qu'on enlève un champ dans une classe dont les instances sont censé à être persistées, on a moins de chance d'enlever ou de rajouter les annotations nécessaires. En effet, lorsque l'on supprime un champ d'une classe on peut difficilement oublier de supprimer l'annotation juste au dessus (si elle existe). Lorsque l'on rajoute un champ, on se rend rapidement compte que les autres sont annotés, donc on pense à annoter le nouveau champ. De plus dans des cas simples le nouveau champ est automatiquement pris en compte dans la persistance. Les manques de synchronisations entre les classes et les fichiers de mapping correspondant arrivent régulièrement. Donc moins d'erreurs.

-        Les fichiers de mapping sont assez chiants à remplir, et honnêtement je pense qu'il est plus facile et plus rapide de rendre une classe persistable avec des annotations qu'avec les balises XML. De plus dans les cas relativement simples (on ne cherche pas a nommer les champs,  ni à borner les chaines de caractères etc.) on n'utilise que deux annotations, une pour la classe et une autre pour l'identifiant. Donc plus de productivité.

-        Les annotations sont utilisées dans JPA ce qui signifie qu'en utilisant des annotations on peut passer plus ou moins facilement à un autre ORM si c'est nécessaire. Donc plus d'indépendance.

Mes collègues, eux n'étaient pas convaincu et pour deux raisons :

-        Persistance ignorance.

-        Les annotations c'est moche. Cela nuit à la lisibilité du code.

Ok...

Effectivement les annotations lorsqu'elles sont nombreuses ne sont pas sexy mais bon, nous sommes des informaticiens pas des artistes (tous mes collègues n'en sont pas convaincus...), plus un fichier de mapping n'a absolument rien de beau. Sur le fait que ça nuit à la lisibilité du code, certes ça rajoute des lignes de code à la classe persistée mais pas tant que ça, et puis pour avoir utilisé (contrairement à eux) les annotations dans le cadre d'un projet JEE5 (avec un vrai client et tout !!) j'avoue n'avoir jamais été gêné par ça, pareil pour les gens avec qui je travaillais. D'ailleurs je vois mal comment les annotations JPA pourraient me ralentir dans la compréhension des classes persistées ainsi que dans la maintenance de celles-ci.

Pour ce qui est de la persistance ignorance, j'ai halluciné, cet argument qui n'en est pas vraiment un, brandi tel un bouclier face à quelque chose que mes collègues ne connaissent pas : les annotations.

Tout d'abord, c'est quoi la persistance ignorance ? C'est le fait de dire qu'une classe qui doit être persistée ne doit pas embarquer d'information permettant de savoir si et comment elle est persistée. Quel sont les buts de la persistance ignorance ? De faire en sorte a ce que les changements de la couche de persistance n'impactent pas les classes censées êtres persistées (qui sont souvent dans le domaine). De faire en sorte à ce que la compréhension du domaine n'implique pas de maitriser le fonctionnement de la couche de persistance. Je précise que ce n'est pas eux qui m'ont expliqué ce qu'était la persistance ignorance.

En quoi la persistance ignorance est débile ? Il y a un gros couplage entre  les classes (du domaine) qui vont être persistées et la manière dont elles vont l'être. Si vous rajoutez un champ à une classe il y a des chances que ce champ doit être persisté. Si vous supprimer un champ, ce champ ne doit plus être persisté. Toute modification des champs d'une classe implique une modification dans la couche de persistance. Donc oui je trouve très débile (pour ne pas dire con...) de cacher au développeur ce couplage. Au final c'est un peu comme du code dupliqué une modification  à un endroit implique souvent une modification à un autre endroit, sauf que cet endroit on ne sait pas toujours où il est. L'approche souvent employé pour lutter contre la duplication de code est de factoriser le code, afin que lorsque l'on effectue une modification à un endroit on n'ait pas besoin de la faire ailleurs. Je pense au contraire qu'en dépit de certains principes scolaires et théorique d'architecture il faut être franc avec le développeur : « Hey, cette classe est persistée n'oublie pas de mettre à jour les informations concernant la persistance !! » plutôt que : « Non, qu'est-ce que tu me racontes là ? Cette classe n'est pas persistée ! (10 minutes plus tard le développeur se rend compte d'une erreur à l'exécution) Hein ? Quoi ? Hibernate t'as lancé une erreur ? Ah ben désolé... ».

J'ai tenté de leur expliquer qu'en utilisant les annotations, une modification de la couche de persistance impliquerait dans le pire des cas une modification des annotations elles même, mais pas de la classe, puisque les champs et les méthodes ne dépendent pas de la couche de persistance. Et que donc, une modification de la couche de persistance n'aurait aucun impacte sur nos vues, nos contrôleurs, nos services etc... Ils n'ont rien voulu savoir. Je pense que leur problème c'est d'être trop scolaire, c'est paradoxal car la plupart ont quittés les bancs de la fac et des écoles d'ingénieurs il y a bien longtemps (plus que moi en tout cas). En fait ils appliquent de « grands » (?!!) principes théoriques sans les comprendre et sans vraiment savoir les appliquer. C'est un peu comme « Jacadi à dit » sauf que là Jacadi est un professeur d'architecture logicielle.