Réflechissons un peu ce matin à propos des ORM

Fri, 11 May 2012 06:34:46 GMT

Fabrice Marguerie (ca faisait une paille que t'avais rien écris ;-)) vient de publier un petit billet qui fait surtout référence à un autre billet de Martin Fowler (vous connaissez bien entendu Martin Fowler).

Le sujet est à propos des outils ORM, Object-Relational Mapping tools.

En gros, ne vous laissez pas aveugler par ces outils, en supputant qu'ils résolvent tous vos problèmes. Ils peuvent couvrir 80% de votre solution, mais il en restera toujours 20% à traiter avec attention.

Et c'est là ou j'ajouterais que si vous choisissez de partir avec un outil d'ORM, il faut impérativement que ce dernier vous permette d'inclure du code personnalisé, que vous ne soyez pas prisonnier de votre ORM. Car la plupart du temps, les 20% de code qu'il vous faut faire à la main, c'est justement les parties les plus délicates, les plus complexes, au niveau de la compréhension du fonctionnel. Et j'ai vu souvent des arguments de développeur indiquant qu'il faut modifier le fonctionnel pour implémenter une fonctionnalité car le choix de leur outil faisait que ce n'était pas possible.

Alors oui je pense à des outils comme NHibernate ou Entity Framework (quoique) qui font que c'est souvent une usine à gaz qui sort des cartons, qui fait que le développeur passe beaucoup de temps à essayer de comprendre comment détourner son ORM pour terminer son petit WorkItem.

Je pense à un outil comme CodeFluent Entities qui lui au contraire est suffisamment maléable, flexible pour intégrer facilement du code personnalisé (mais qui d'un autre côté vous génère 80% de votre plomberie). Il a même été conçu dans ce sens.

Donc je le répète, faites attention à l'ORM que vous choisissez. Pensez que quand vous choisissez un ORM, cela vous engage pour toute la durée du produit (et pas seulement le temps de son développement), et surtout, soyez certain qu'il y aura des features non couvertes par votre ORM.

c2i.fr - ORM

Réflechissons un peu ce matin à propos des ORM