+- 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 : [Framework] Avantages et inconvénients ? (/showthread.php?tid=2900)
RE: [Framework] Avantages et inconvénients ? - pascal - 18-08-2008
en 5 ans, j'ai changé une seule fois de DB : mysql -> Sql Server.
je pense qu'il faut faire au cas par cas, pour l'ORM, la DAO, etc :
- le conserver pour les choses simples
- en cas de soucis, passer par un accès "maison" à la DB, en suivant des régles pour que ça reste "propre"
A+
Pascal
RE: [Framework] Avantages et inconvénients ? - Sephi-Chan - 18-08-2008
Personnellement, mon petit plaisir c'est d'avoir un objet sexy après une requête. À ce niveau, même MySQLi me convient. L'idéal — toujours selon moi — c'est de pouvoir appeler les choses d'une manière peu verbeuse, pour ça, j'adore le système de CakePHP à coup de convention de nommage (que l'on peut surcharger si l'on ne les respecte pas, naturellement), qui permet d'appeler les choses comme cela (dans les actions de mon contrôleur) :
Code PHP :
<?php
$monObjet = $this->MonModel->query(/* Ma requête SQL. */);
L'ORM, je trouve ça amusant mais pas franchement utile. La génération de requête, c'est sexy, c'est sûr, mais c'est très gadget. C'est tout de même plus rapide d'écrire sa requête à la main.
Sephi-Chan
RE: [Framework] Avantages et inconvénients ? - Asther - 18-08-2008
c'est ce que je pense aussi ca evite en meme temps de devoir replonger dans la methode si ont doit ajouter un champs ensuite etc... ou alors ca peut etre utile sur une requette ou l'ont est sur qu'elle ne changeras pas, mais bon.
RE: [Framework] Avantages et inconvénients ? - zzarbi - 18-08-2008
Personnellement, je suis en train de développer mon propre système de DAO/ORM mais en gardant le coté optimisation.
Je veux dire, il y a des requêtes simple qui ne peuvent pas être optimisé qui sont tous le temps pareil :
- Select sur une table
- Update sur une table
- Delete sur une table
Ces trois type de requêtes peuvent largement être générer à la volé avant la création du projet.
Mon idée est de prendre un logiciel de création de DB (Dbdesigner 4 par exemple). Une fois qu'on a une BDD, on génère un fichier XML avec le logiciel et on le parse avec un sous-projet pour générer les bo/dao avec des requetes simple, le tout héritant d'une classe DAO/BO abstract.
Donc on aurait 2 fichiers par table : Un BO et un DAO.
EN gros on pourra ensuite faire du :
$MonObjetDAO->GetAllByID($id);
ou
$MonObjetDAO->Select('$requete');
ou
$MonObjetDAO->Select('champs1;champs2;champs3','Table2;Table1','Gestion du WHERE');
ou
$MonObjetDAO->Update(ObjetBO);
etc...
Maintenant, le truc pratique en objet pour la maintenance c'est de mettre toute les requêtes SQL dans la partie DAO. Et la ça devient compliqué, car si on modifie les classes générer on ne peut plus les régénérer car on perdrait le code qu'on a modifier. Il reste donc alors de créer des classes à la main qui hériterait des classe générées, où l'on rajouterai nos requêtes perso. Comme ça on garde la séparation CODE SQL/CODE PHP. Ou tout simplement créer de nouvelles classes qui ne correspondrait pas à un objet en particulier mais à une fonction...
Liste des avantages :
- Une partie du code est générer : bo/dao
- Possibilité de faire des requêtes complexe sans perte d'optimisation.
- Possibilité de générer les classes en fonction d'une classe d'abstraction et donc avoir la possibilité de changer de BDD (Mais je ne garderait pas cette idée, vu qu'on perd de l'optimisation)
Enfin bref c'est une idée comme un autre... ^^
PS : Enfin on peut optimiser le tout eau niveau du développeur en intégrant à son IDE des outils lui permettant de développer plus rapidement.
Par exemple avec Zend Studio, on a accé à tous les objet, mais si on pouvait avoir assez à un genre de structure, qui représenterait une table et ses champs.
Comme ça on pourrait faire en gros:
$MonObjetDAO->Select(Table.champs1,Table.Champs2) (Complètement fictif comme example)
Mais ça serai l'IDE qui proposerait les champs...
RE: [Framework] Avantages et inconvénients ? - zzarbi - 18-08-2008
Oui mais même dans un jeu il y a énormément de requête simple... Donc pouvoir générer cette partie reste intéressante.
RE: [Framework] Avantages et inconvénients ? - pascal - 18-08-2008
le "je peux changer de SGBD", c'est vrai, ça sert très peu. l'abstraction permet d'ajouter des fonctionnalités dans l'exécution des requêtes ( log, comptage... en dev mais pas en prod, selon la config )
zzarbi, ce que tu proposes c'est de refaire un DAO
oxman, ce que tu veux, c'est faire des requêtes
on peut faire l'un et l'autre avec propel et ce qu'il y a derrière : creole
comme toujours, il faut être pragmatique et utiliser le bon outil au bon moment :
- propel pour le CRUD, genre une simple messagerie
- creole pour des requêtes complexes, comme le coeur d'un système de combat
je garde symfony, propel & co pour mes projets de sites et de jeux !
A+
Pascal
RE: [Framework] Avantages et inconvénients ? - Sephi-Chan - 18-08-2008
Je ne trouve pas que ce soit une grosse perte, car même si ça fait gagner un peu de temps sur une requête simple. Ça exige un certain temps de développement. Si c'est fait de manière légère, pourquoi pas. Notamment en générant tout seul le fichier XML (à l'aide d'un DESCRIBE). Si le développeur veut activer le LightORM, il lance un bête script qui génère les fichiers utilisés sans qu'il n'ai rien à faire de plus.
Ce serait la classe.
Sephi-Chan
RE: [Framework] Avantages et inconvénients ? - zzarbi - 18-08-2008
pascal a écrit :zzarbi, ce que tu proposes c'est de refaire un DAOOui je veux faire un DAO, car je n'ai rien vu d'intéressant ou qui réponde à mes attentes en entier....
oxman, ce que tu veux, c'est faire des requêtes
pascal a écrit :on peut faire l'un et l'autre avec propel et ce qu'il y a derrière : creoleEh bien j'ai regardé propel et j'ai pas trouvé de solution pour faire ce que je veux...
comme toujours, il faut être pragmatique et utiliser le bon outil au bon moment :
- propel pour le CRUD, genre une simple messagerie
- creole pour des requêtes complexes, comme le coeur d'un système de combat
RE: [Framework] Avantages et inconvénients ? - QuentinC - 18-08-2008
JE risque de passer pour un alien qui sort d'un trou 10 pages plus tard, mais...
1 - Qu'est-ce qu'un ORM et un DAO ?
Même après 10 pages de topic, une recherche sur google et une sur wikipedia fr+en, je n'ai pas su trouver une ddéfinition objective de ces deux termes.
2 - Quel est l'intérêt de faire générer des requêtes SQL par une moulinette php plutôt que le faire directement soi-même ?
Là non plus, après plusieurs lectures, je ne vois toujours pas l'intérêt de faire ça, pas plus que d'utiliser un moteur de template.
Si on sépart son code en deux parties bien claires, d'une part le traitement des données et d'autre part leur affichage, et une troisième pour orchestrer les deux, je ne vois pas l'intérêt d'utiliser une surcouche, php joue lui-même parfaitement le rôle de moteur de template. ON limitera le code d'affichage à echo, if/elif/else, foreach, appel de fonction simple genre htmlentities et paf, on a tous les ingrédients nécessaires.
Le reste, c'est pour changer la syntaxe, pour ne pas la simplifier beaucou d'ailleurs, enfin question de goût.
Côté DB, ça a l'air d'être pareil : le SQL est trop compliqué, alors on produit des routines encore plus compliquées qui écrivent du SQL pour nous... est-ce que c'est *réellement* plus simple qu'avant ? j'en doute sincèrement.
C'est comme pour l'OO, autant j'aime bien celle de java, autant celle de php me rebute, je ne sais pas trop pourquoi, il y a certaines choses qui me paraissent bizarres...
Au fait j'essairais bien ruby (attention : ruby tout court le langage de programmation, pas ruby on rail le framework) pour le web... Leur politique a l'air d'être « simple, concis et efficace » et « on ne prend pas 15 détours pour faire un truc même s'il y a 15 façons différentes de le faire ».
Si je trouve comment coller mod_ruby à wamp5, je tenterais bien le coup, juste pour essayer les possibilités offertes par la bête.
RE: [Framework] Avantages et inconvénients ? - zzarbi - 18-08-2008
QuentinC a écrit :JE risque de passer pour un alien qui sort d'un trou 10 pages plus tard, mais...Un alien ptet pas ^^
QuentinC a écrit :1 - Qu'est-ce qu'un ORM et un DAO ?Alors pour le DAO c'est simple et sans parler de (génération de requetes) ca pourrait t'être utile...
Même après 10 pages de topic, une recherche sur google et une sur wikipedia fr+en, je n'ai pas su trouver une définition objective de ces deux termes.
http://fr.wikipedia.org/wiki/Objet_d%27acc%C3%A8s_aux_donn%C3%A9es
Le but est simplement de séparer le code des requêtes SQL/XML etc...
Exactement comme un moteur de template en effet.
En gros t'as 2 fichiers, un fichier qui rassemble les données (rassemblement de variables, tableau, objet, etc...)
Et un deuxième fichier qui gère ses "objets", les stock en BDD en XML etc...
Ensuite t'es pas obliger de faire de la génération requête, tu peux tout écrire à la main.
Mais l'utilité de pouvoir séparer son "code" sql de son code PHP est franchement utile, autant que la gestion de template (qu'elle soit fait en PHP ou en surcouche PHP).
Pour l'ORM c'est plus compliqué...
Le but est de simuler une base de donnée objet. Tous ce qu'il apporte c'est du confort au développeur au détriment des performances. C'est pour ça que je ne veux pas utiliser ce genre de système. :/
Cependant tout comme certaines technologies, elle peuvent servir de prototype. En effet il peut arriver qu'on doivent déployé rapidement une application de test où les performances ne sont pas primordiale, en entreprise on rencontre souvent cette problématique.
QuentinC a écrit :2 - Quel est l'intérêt de faire générer des requêtes SQL par une moulinette php plutôt que le faire directement soi-même ?[EDIT]On ne génère pas des requetes à la volée !!!!! On génère des fichiers pour le développement du projet! Faut faire attention ^^[EDIT]
Ah ça c'est de la flaimardise dans un sens, mais il faut quand même développer le code qui génèrera les requêtes.
Le but étant d'avoir un "moteur" réutilisable si on change de projet.
Tu vas pas me dire qu'à chaque projet tes requêtes SQL Changent...
Donc l'interet sur un unique projet est inutile, mais sur plusieurs elle est bien là !
Imaginons que t'a une pièces en plastique à faire, tu dois en faire un million. T'a 2 choix :
- Les usiner à chaque fois, prix à la pièces : 2€
- Faire un moule 1000€, prix à la pièces : 0.5€
Sur un million... Tu fais une économie non négligeable.
C'est pareil dans le code. Ça permet selon les projets d'avoir plus ou moins 20% du code générer...
Et je suis quasiment sûr que sur du "requetage" simple tu peux pas faire une application plus rapide... Mais je suis d'accord que du dois prendre presque le double de temps sur un projet unique !!! Mais c'est dans le but du multi projet !!! Mais même si on ne fait que rajouter des tables dans X temps ça reste intéressants.
QuentinC a écrit :Là non plus, après plusieurs lectures, je ne vois toujours pas l'intérêt de faire ça, pas plus que d'utiliser un moteur de template.Mais non, pour le coté templates je suis d'accord que c'est idiot de faire une surcouche de PHP, surtout qu'il faut parser le templates etc...
Si on sépart son code en deux parties bien claires, d'une part le traitement des données et d'autre part leur affichage, et une troisième pour orchestrer les deux, je ne vois pas l'intérêt d'utiliser une surcouche, php joue lui-même parfaitement le rôle de moteur de template. ON limitera le code d'affichage à echo, if/elif/else, foreach, appel de fonction simple genre htmlentities et paf, on a tous les ingrédients nécessaires.
Le reste, c'est pour changer la syntaxe, pour ne pas la simplifier beaucou d'ailleurs, enfin question de goût.
Côté DB, ça a l'air d'être pareil : le SQL est trop compliqué, alors on produit des routines encore plus compliquées qui écrivent du SQL pour nous... est-ce que c'est *réellement* plus simple qu'avant ? j'en doute sincèrement.
Et donc ça n'apporte rien dans le simple cadre de template.
Mais voila smarty par exemple apporte la gestion du cache, et d'autre outils plutôt intéressant que tu ne pourra pas faire en PHP sans apporter du code.
Par contre et c'est la qu'on voit que tu n'as pas compris le coté génération de classe à partir de BDD... EN disant que le SQL c'est compliqué... Eh oui dans la génération de requête SQL on fait quand même du code SQL on doit bien la générer... Donc ça nous évite pas le code SQL... Ca permet au contraire d'éviter de se taper le même code super simple de SQL. Du genre Select * from id= '';...
Pour les requetes plus complexe on doit quand même l'écrire, sauf dans le cas de l'ORM oule principe est de simuler une base de donnée OBJETS. Et donc ce n'est pas la même chose du tout.