Data Access Object (DAO) - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : Data Access Object (DAO) (/showthread.php?tid=4410) |
Data Access Object (DAO) - My Hotel - 14-10-2009 Salut à tous! J'hésite en ce moment à utiliser des DAO... Qu'en pensez-vous? Utile ou pas pour un jeu PHP? Quels sont les avantages, inconvénients? Comment vous en servez-vous? Voilà, j'espère que ça va m'aider à me décider Bye RE: Data Access Object (DAO) - Sephi-Chan - 14-10-2009 J'aime les DAO, j'utilise ActiveRecord (c'est celui par défaut de Ruby on Rails). Pour un jeu par navigateur, les avantages sont conséquents et les défauts moindres. Parmi les avantages les plus évident : la facilité de maintenance et la fiabilité. Je prends l'exemple d'un modèle de mon jeu (à l'heure où j'écris les lignes, il est encore assez basique). Il s'agit du modèle Neighbourhood qui modélise un lien de voisinage (unilatéral) entre deux territoires.
D'une, on peut spécifier les association du modèle. Si j'ai un objet Neighbourhood, je peux facilement récupérer son territoire source (en appelant la méthode territory) et son territoire de destination (avec la méthode neighour). Cela me renverra des objets Territory qui auront eux-même leurs propres associations (par exemple en appelant la méthode neighbours sur un objet territoire, j'obtiens tous les territoires associés (grâce à une relation plusieurs-à-plusieurs qui utilise Neighbourhood comme modèle de de jointure). De plus, les règles de validations rendent le modèle fiable. C'est centralisé, on ne risque jamais de l'oublier. En plus des règles de validation (très riches), on peut mettre des callbacks (avant/après la validation, avant/après la sauvegarde (et on peut différencier création et modification), avant/après la destruction, etc), donc à nouveau ça permet une centralisation très claire. Parmi les défauts, on a les performances. Bien sûr si je fais User.all avec une table de 15 000 utilisateurs, ça va prendre un peu de temps d'instancier autant d'objets, mais on fait rarement ce genre de choses… L'autre avantage aussi, c'est que l'objet permet très simplement d'ajouter un système de cache : il suffit de modifier les accesseurs. Enfin, car ça peut en rebuter, le SQL est généré intelligemment. Il y a moyen de faire beaucoup de choses avant d'avoir besoin de taper du SQL à la main (et ça reste très simple à faire). Pour les sceptiques à propos de l'efficacité des requêtes générée, une petite vidéo qui montre en action deux outils qui permettent de générer des jointures include et join (ou non, selon les cas). Sephi-Chan RE: Data Access Object (DAO) - Anthor - 15-10-2009 (14-10-2009, 07:51 PM)Sephi-Chan a écrit : Enfin, car ça peut en rebuter, le SQL est généré intelligemment. Je rajouterais qu'il est aussi souvent plus propre et mieux optimisé que celui écrit à la main RE: Data Access Object (DAO) - My Hotel - 18-10-2009 Et au niveau des jointures, comment ça se passe, sans framework bien sûr... Parce que je pense que c'est malheureusement plus compliqué qu'un simple " belongs_to :territory ", non? RE: Data Access Object (DAO) - Sephi-Chan - 18-10-2009 Ça se fait de manière transparente :
Par défaut, Ruby on Rails fait du lazy loading, mais si tu veux charger d'un coup les données (par exemple pour charger en une seule fois des news et leurs commentaires, pour pas que le chargement à la volée fasse une requête par news pour choper les commentaires) :
Sephi-Chan RE: Data Access Object (DAO) - My Hotel - 18-10-2009 Merci pour cette réponse, mais c'est moi où au finale, ça fait plus de requêtes? Et si oui, est-ce que ça vaut vraiment le coup en PHP, ou y'a qu'en RoR que c'est génial RE: Data Access Object (DAO) - Sephi-Chan - 18-10-2009 Ça fait les requêtes de manière plus intelligentes. Cela dit, il faut que le développeur soit malin. Admettons qu'on ai ce modèle, tout simple :
Ça dit quoi ?
Dans le contrôleur :
Là aussi, c'est simple : on sélectionne les posts publiés en paginant. On indique que le paramètre d'URL qui indique la page parcourue se nomme "page". On met tout ça dans une variable d'instance (comme l'indique le @) @posts, qui sera donc accessible dans la vue. Dans la vue :
Le problème, c'est que Rails va lancer une requête pour chaque post, puisqu'à chaque itération, on va lui demander de compter les commentaires ! On va donc avoir un total de (nombre de posts + 1) requête ! Pour n'avoir que 2 requêtes (une pour récupérer les posts et une autre pour les commentaires de ces posts), on va modifier un peu le contrôleur :
Et voilà ! Et les ORM pour les autres langages, je suppose qu'elles sont bonnes, mais je ne les ai jamais utilisé "sérieusement" donc je ne peux pas me prononcer à leur sujet. Ce que j'aime dans ActiveRecord, c'est son intégration avec Rails, la création très simple de liens, la génération éléments HTML avec les attributs class et id qui vont bien, etc. Sephi-Chan RE: Data Access Object (DAO) - Hakushi - 22-10-2009 Bien que le DAO ait ses avantages, il faut savoir reconnaitre quand il est necessaire ou non d'y avoir recours. J'y ai par exemple beaucoup recourt dans du back-end (CMS majoriterement), via Zend Framework (dont l'implementation ressemble beaucoup a ActiveRecord), alors qu'a l'opposé, sous un lourd traffic (surement hors de consideration dans le cas present, mais sait on jamais), on essaye d'exclure au maximum le nombre de couche du site, couches qui créent une charge souvent inutile. Ce sont des pratiques tout a fait valable, il faut simplement en connaitre les limites et quand les utiliser. |