[Framework] Avantages et inconvénients ?

[zzarbi]

JE risque de passer pour un alien qui sort d'un trou 10 pages plus tard, mais...

Un alien ptet pas ^^

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 définition objective de ces deux termes.

Alors pour le DAO c'est simple et sans parler de (génération de requetes) ca pourrait t'être utile...
http://fr.wikipedia.org/wiki/Objet_d%27a...nn%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.

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.

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.

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...
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.