Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 2 sur 2
  1. #1
    Invité de passage
    Homme Profil pro Denis Beurive
    Inscrit en
    octobre 2012
    Messages
    13
    Détails du profil
    Informations personnelles :
    Nom : Homme Denis Beurive
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : octobre 2012
    Messages : 13
    Points : 1
    Points
    1

    Par défaut Retour d’expérience sur Active Record?

    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

  2. #2
    ovh
    ovh est déconnecté
    Rédacteur
    Avatar de ovh
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2002
    Messages
    3 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2002
    Messages : 3 761
    Points : 5 896
    Points
    5 896

    Par défaut

    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
    Tutoriels sur les UPS, e-commerce, PHP, critiques de livres...

    Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles.
    Je n'ai rien à voir avec la société www.ovh.com !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •