Anthony Patricio’s Blog

Foutaises, apprenez à les détecter

Posted in Actu / Anecdote by apatricio on mai 15, 2009

Tout travail mérite le respect, la réflexion et le temps passé à concevoir et implémenter une solution ne peuvent être directement et gratuitement fustigés.

Il en va différemment lorsque les auteurs s’exposent eux-mêmes en lançant une information agressive et fausse (aka F.U.D) avec d’autres produits.

C’est ce qu’il s’est passé ici où l’on nous ressort un DataMapper basé sur des patterns anciens voire du millénaire passé comme commenté sur la page:

Honestly, the approach is old. I know that I’ve used similar approach going back to 1999 and it was old back then.

Reprenons depuis le début, le produit présenté n’a rien d’un ORM (Object Relationnal Mapping) dès lors qu’il impose d’énormes limitations au modèle objet, comme la non prise en charge de l’héritage et surtout qu’il ne propose pas de mapping… ben oui forcément. Ici il s’agit en fait d’imposer, via un framework, une organisation/une structuration du code dans des classes stéréotypées. L’idée est louable, toujours meilleures que d’avoir du JDBC pur non organisé et explosé partout dans un projet.

Cependant, c’est assez préhistorique et très franchement pénalisant sur beaucoup de points, lisons entre les lignes :

No lazy loading. Just eager loading because you can expect whatever you want during coding. Eager loading removes n + 1 queries.

Mouais, c’est un peu beaucoup n’importe quoi. Le lazy loading peut effectivement entraîner un soucis de n + 1 requêtes mais uniquement si le développeur est un lazy développeur (= développeur fainéant). Avec un ORM et hibernate en particulier, tout est fait pour pouvoir optimiser les modes de récupération de graphe d’objets. En passant « just eager loading » tend à forcer le chargement entier des graphes d’objets. Ceci est purement unitle et simplement consommateur de ressources. D’où l’existence d’une fonctionnalité comme le lazy loading qui permet de charger uniquement la portion de graphe nécessaire à un cas d’utilisation. Le lazy loading bouchonne le reste du graphe avec des proxies qui permettront eux-même le chargement transparent du reste du graphe en cas de nécessité, comprende? … la boucle est bouclée

an entity object which extends POJO

Comme le dirait un de mes bons amis:  « namuf ? » (= quoi?, kékidi? ou encore C’est une blague?). Pour faire court, simple et pour ceux qui n’ont pas tilté, un POJO est un objet pur, qui ne dépend d’aucun framework, encore moins technique. Un POJO est libre et peut être exploité par un client sans que l’on ait besoin de déployer une quelconque armada de jars de frameworks techniques au risque de se prendre une ClassNotFoundException.

Notre ami nous explique donc que les classes persistantes utilisées avec son framework doivent étendre une classe technique, présente dans son framework, classe qui se nomme très intelligemment POJO. C’est fantastique! Forcément et probablement sans même savoir pourquoi, il a du compléter son framework de convertisseurs:

built-in converter that can be used to convert a Java Object into a frontend String or a frontend String into a backend Java Object. The converter prevents data conversion from scattering different pages and layers.

Beh oui, les objets n’étant pas des POJOS, ils deviennent difficilement manipulables d’une couche à l’autre. Il faut passer par le bon vieux DTO, à savoir un POJO destiné essentiellement à des fins de manipulation de données. Et pour automatiser la transposition d’un « truc » (désolé ses trucs ne sont pas des POJOS pour moi) vers un DTO, que faut-il? Des convertisseurs, bravo. Il va forcément falloir gérer ces conversions de manière systématique, typiquement entre la couche service et la couche web.

Ces traitements sont coûteux en terme de développement et de maintenance, complètement inutile car ne contenant aucune plu value métier et forcément c’est vraiment contre productif. Mais non puisque notre ami nous affirme gratuitement:

High productivity compared to Hibernate.

Sans exagérer 70% de ce que dit l’auteur est faux et je vais arréter là, … euh, … aller une dernière pour la route, lisez attentivement le titre est les premiers mots du commentaire ici (écrit par l’auteur du framework lui-même. ):

No limitation

suivi de

There are no polymorphic queries

Comme c’est beau, il m’a convaincu!

Tout ceci ne veut pas dire que le framework est inutile ou mauvais, il ne répond simplement pas à un outil du spectre d’un ORM. En le aisant délibérement, l’auteur s’est tiré une balle dans le pied.

J’ai connu et connais encore plusieurs décideurs qui se laissent berner par ce type d’argumentation. Résultat: des applications qui utilisent des technos d’un autre millénaire (ce qui n’est pas grave) mais qui passent aussi à côté de technos pouvant résuire sensiblement les coûts de développement, de maintenance et d’évolution. Prenez une application de 50 tables avec 1000 requêtes SQL codées en dure, forcément pas le choix avec un DataMapper, il faut en coder une par cas d’utilisation. Ajoutez une colonne par ci par là lors d’une évolution, vous m’en direz des nouvelles…

Apprenez à lire entre les lignes et si vous êtes décideur sans être expert sur un sujet en particulier, déléguez à un de vos petits gars passionnés. Il vous fera gagner beaucoup d’argent à terme, croyez-moi. De même, méfiez-vous toujours des software marabous qui vous vendent une bidouille propriétaire  sortie du chapeau et qui vous certifie qu’elle est bien meilleure que les frameworks les plus robustes, matures et éprouvés.

Publicités
Tagged with: , , ,

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :