A lire ou à regarder et écouter sur TheServerSide l’interview de Ted Neward. Le personnage est haut en couleur et ne dis pas que des bêtises. Difficile de s’y résoudre mais il a raison, il faudra bien que je finisse par mettre un peu de .net dans mon CV.

J’aime beaucoup son exemple pour expliquer qu’il préfère les “designs patterns” aux “best practices”:
Une bonne pratique est de toujours veiller à libérer les ressources que l’on utilise une fois que le programme a fini de s’exécuter. Mais dans le cas d’un programme embarqué de guidage d’un missile…Ce n’est pas forcément très utile. Les best practices n’existent pas, il n’y a que des problèmes et des solutions qui s’appliquent dans un certain contexte.

Et j’adore son exemple pour illustrer le concept de communication avec où sans état.

Conversation avec état:
– Bonjour Jean, tu veux aller déjeuner?
– Bien sûr Paul, où allons nous?
– Pourquoi pas le restaurant Italien?
– Super, quand y allons nous?
– A midi.

Conversation sans état:
– Bonjour Jean, tu veux aller déjeuner?
– Bien sûr Paul, je veux aller déjeuner, où allons nous?
– Allons déjeuner au restaurant Italien, Jean.
– Super Paul, allons déjeuner au restaurant Italien mais à quelle heure?
– Jean nous allons déjeuner au restaurant Italien à midi.

Un protocole de communication sans état doit en permanence transporter tout le contexte.

Que ceux qui travaillent en mémoire avec des objets et qui persistent ces mêmes objets dans une base de données relationnelles lèvent le doight…

Hibernate et Toplink avant lui sont des “messies” pour résoudre le fameux problème du mapping objet relationnel. Mais utiliser ces frameworks pour résoudre le problème ne garantit pas le succès. Il faut comprendre la différence entre la conception orienté objet et le monde des bases de données relationnelle, le fameux “Impedance mismatch”. Je vous recommande donc la lecture de cette publication : Modèles relationnel et objet qui fait très bien le tour de la question.

Si il n’y avait qu’une seule chose à retenir:
Dans le monde relationnel on calcul (jointures, indexes…) l’accès aux données alors que dans le monde objet on parcours un model (pointeurs). Les conséquences? L’objet permet d’obtenir un modèle plus proche de la réalité et donc utile pour traiter des problèmes complexes. Par contre il est beaucoup plus dur de mettre à jour une données dans un modèle objet que dans un modèle relationnel.

Je veux travailler avec une base de données objet !!!!