Administrateur PHPfrance |
3131 Messages
14 janv. 2009, 13:13
Bonjour,
Est ce qu'un framework a réellement un intéret lorsque l'on a déjà ses petits scripts que l'on ajoute ou retire aux sites que l'on fait ?
Un framework n'a pas juste un intérêt, il est simplement indispensable d'avoir une boite à outils pour développer correctement. Que cette boite à outils soit sa propre librairie personnelle ou un framework tiers ça a finalement peu d'importance.
En fait, en général on suite ce chemin :
- On utilise un framework (sans vraiment s'en douter) développé soi-même souvent appelé "libs.inc.php".
- On découvre ensuite "include_once" et ses vertus, et notre framework devient un dossier "libs" avec plein de fichiers bourrés de fonctions dedans.
- On découvre ensuite la POO, et les fichiers bourrés de fonctions deviennent des fichiers avec une classe et plein de méthodes. En général à peu près là, on découvre l'existence des gros frameworks (genre Zend ou Symfony) et on se demande si ce serait pas mal.
- Puis on apprend à se servir de la POO, et les classes avec plein de fonctions statiques deviennent des vraies classes. En général à ce stade on regarde les gros frameworks en se disant "pouarf ! quels usines à gaz" (souvent en pensant à la partie "ORM" de ces frameworks d'ailleurs).
- Dans ces eaux-là on découvre les "design patterns" (patrons de conception orientés objet), et les modèles de développement (genre "MVC") et on s'interroge...
- Puis on finit par se dire que des centaines de développeurs font sans doute un meilleur travail que soi-même tout seul dans son coin, et que les gros framework ne sont peut-être pas si mal, surtout parce que le dossier "libs" commence à devenir sérieusement compliqué à maintenir, et qu'on trouverait pas mal d'avoir un truc qui soit mis à jour par d'autres finalement...
Ex. Est ce que tout le monde ne va pas adopter une hiérarchisation de ses fichiers façon mvc ? Si c'est juste une mode, ça ne m'intéresse pas mais si ca va se généraliser d'ici quelques temps
C'est déjà généralisé. Déjà rien que si tu utilises des templates, et que tu évites de faire des requêtes SQL partout en plein milieu du code (mais que tu vas plutôt les isoler dans des fonctions dédiées à la manipulation des données), tu fais du MVC :
- Modèle = tes fonctions de manipulation des données.
- Vue = tes templates.
- Contrôleur = la glue qui gère tout ça ensemble (typiquement ton "index.php" qui inclut tel ou tel fichier en fonction de la valeur de $_GET['page']).
Donc tu n'est probablement pas très loin d'utiliser du MVC "strict" avec une séparation plus complète des couches, et une partie "Modèle" plus évoluée.
Secondement, je me demande si un framework ne s'adresse pas, un peu comme les cms, à ceux qui ne savent pas coder en php. Exemple personnel, je n'y connais rien en javascript et pour pallier à ca je vais me lancer dans le framework jQuery qui me semble plus accessible que replonger dans des cours de A à Z javascript.
C'est plus ou moins vrai. On pourrait croire ça (cf. ta démarche avec jQuery) mais ça se limitera à de très simples opérations. Dès que tu voudras faire quoi que ce soit d'un peu évolué, tu te rendras compte qu'au contraire il vaut mieux très bien maitriser le langage (et donc de ne pas avoir grillé les étapes dont j'ai parlé plus haut) pour utiliser correctement un framework, car il est nécessaire d'avoir au moins une petite idée de ce qui se passe derrière pour ne pas se retrouver complètement penaud devant un truc simple.
Au niveau de l'architecture mvc ? Est ce qu'elle apporte réellement quelque chose (pour le moment je ne vois que l'interêt que design et php soient séparé mais je ne travaille pas en équipe) ?
Mode ou plutôt nouvelle norme ?
Oui elle apporte une organisation strict et tout ce qui est restrictif améliore généralement la qualité dans le sens "facilité d'évolution et de reprise ultérieure".
Et ce n'est ni une mode ni une nouvelle norme, c'est une norme qui commence à devenir ancienne
