Discussion :

[denis.beurive]

Bonjour à tous,

Je découvre ROR depuis quelques jours, et je m’intéresse à l’abstraction de base de données.

Remarque : J’ai déjà utilisé des frameworks MVC tels que ZF ou Codeignitor.

J’ai vu le concept de « migration ». Je me demande si c’est bien utile.

Je lis que les migrations sont utiles pour garder une trace des modifications apportées au schéma de la base. OK, mais :

Si vous voulez garder une trace de toutes les modifications apportées sur le schéma d’une base, pourquoi ne pas conserver ce schéma dans un outil de gestion de version, tout simplement ? (Exemples : Git, SVN ou autre).

Je lis que les migrations sont utilisées pour garder une trace des modifications apportées au contenu de la base. OK, mais :

Vous ne devriez pas modifier la base directement en production. Et si vous êtes amené à le faire, vous devriez faire une sauvegarde de cette dernière avant... on ne sait jamais. D’ailleurs, si vous utilisez les migrations, il serait bon de mes tester avant ! Et puis, tout changement n’est pas réversible ! La sauvegarde est, dans tous les cas, indispensable.

D’autre part, en ce qui concerne l’interface de sélection, je constate qu’elle est très similaire à celle de ZF.

Et mon expérience de ZF m’a appris cela :

Quand vous développez une grosse application, vous devez écrire de grosses requêtes avec des jointures de différents types, en utilisant des fonctions SQL...

Dans ces conditions la couche d’abstraction devient un énorme boulet.

• Vous devez bien connaître le schéma de votre base pour l’utiliser efficacement.
• Vous devez bien connaître, dans les plus petits détails, les subtilités (très mal documentées) de la couche d’abstraction.

Vous vous retrouvez à écrire de longues suites d’appels de méthodes avec des options...

Et vous vous dites :

C’est illisible ! Une simple requête SQL bien présentée (indentation, commentaires...) est 100 fois plus lisible !

On va vous dire :

Oui, mais, si un jour tu veux passer de MySql à Oracle, tu peux le faire sans changer une ligne de code !

Oui, mais... avez-vous déjà changé de base de données ?

Et si vous le faites, ce ne sera pas avant 3 ou 4 ans... D’ici là, votre framework aura évolué... Et vous serez obligé de modifier le code.

Et puis on ne change pas de base pour le plaisir. En général, un tel changement est motivé par un problème de fond. Ce changement s’accompagne d’autres changements...



Je me pose la question de l’intérêt d’utiliser Active Record pour les gros projets.

Quel retour d’expérience avez-vous ?

Utilisez-vous toute l’artillerie Rails ? (les migrations...).

Est-il possible de se passer d’Acive Record ?

Merci,

Denis

[ovh]

Tu peux très bien utiliser un ORM et faire des jointures pour optimiser les requêtes en base, ce n'est pas incompatible
Après, c'est sûr qu'un ORM même utilisé de manière optimisée sera toujours moins performant qu'un accès "pur" à la base.
Il y a aussi moyen de faire un compromis en utilisant les facilités de l'ORM pour la persistance des entités métier et la facilité de l'orienté objet, et de le "débrancher" ponctuellement pour les requêtes complexes en utilisant du SQL pur (pour aller interroger des vues ou exécuter des procédures stockées par exemple). C'est ce qu'on fait en ce moment au boulot pour une grosse appli avec Doctrine2 en PHP.

Pour revenir spécifiquement au design pattern Active record, c'est mal...

Quelques lectures qui détaillent pourquoi :
http://stackoverflow.com/questions/1...and-propel-1-6
http://programmers.stackexchange.com...ign-principles
http://misko.hevery.com/2009/05/05/t...active-record/

En résumé, le problème d'active record, c'est le couplage très fort entre les classes métier et la couche persistance.
La plupart des ORM ou des couches d'accès aux données de frameworks classiques tels que Zend suivent le pattern active record parce que c'est plus simple...

Mais Doctrine 2 (PHP) et SQL Alchemy (Python) sont 2 ORM à contre-courant basés sur le pattern data mapper : ils sont tous 2 très fortement inspirés par le célèbre ORM Hibernate (java) dont ils reprennent quasi tous les concepts. Je ne connais pas trop Ruby, mais à ce que j'ai vu il existe aussi un ORM en data mapper, simplement DataMapper http://datamapper.org/why.html