Frameworks

[naholyr]

Par exemple, les gens disent "les couches d'abstraction de base de donnée ça claque, on peut changer de SGBD sans changer les requêtes", Ok. Ça sert souvent dans un projet ?

ça m'est arrivé une seule fois dans un projet : dans le cahier des charges on note comme pré-requis "PHP5+Apache+MySql sur serveur Linux". Le projet se termine, on freeze, on empaquète, et on livre. Et voilà qu'au moment de la mise en prod, on se retrouve face à un serveur "PHP5+IIS+SQL Server sur Win2003"...

J'ai changé une ligne dans la conf d'accès db du projet (le champ "dsn" de databases.yml), j'ai lancé une commande (symfony propel-build-all) et miracle ça a marché en utilisant SQLite en lieu et place de MySQL (mauvaises expériences avec SQL Server, j'ai préféré assurer) Résultat : le client est ravi car le projet a été mis en prod à la date prévue, malgré des pré-requis non respectés (en revanche s'il veut avoir accès à la garantie il aura évidemment à acheter un serveur correspondant au pré-requis du CaCH, et là à nouveau merci Symfony, la migration se fera en 3 commandes, sans avoir à installer un quelconque dbmanager).
C'eût été totalement impossible hors de l'utilisation d'un framework incluant des facilités de déploiement et une couche d'abstraction haute d'accès à la bdd. Et ça aurait simplement remis totalement en cause la mise en prod, repoussée de plusieurs semaines le temps pour le client d'acquérir et de configurer le serveur. Autant de chiffre d'affaires non généré pour lui, et il n'aurait pas été autant satisfait, alors que là il a été tellement impressionné qu'on est garantis de travailler à nouveau avec lui

On dit aussi "si mon système de combat change, j'ai juste à modifier la classe de combat", Ok. Est-ce impossible de faire ça sans utiliser de classe super divisées ?

Non, mais tu admettras que c'est beaucoup plus compliqué, et que l'autoloader permet de simplifier grandement ce processus quand on travaille avec des classes (pour le pattern factory par exemple, typiquement utilisé quand on veut avoir accès à plusieurs «façons de faire» pour une même méthode).

Comme souvent, tout est question de besoin, et dans un jeu développé en PHP je doute que multiplier les couches soit utiles. Je ne dis pas que c'est mauvais, juste que c'est sans intérêt. On peut faire les choses de manière modulaire sans pour autant utiliser de Framework.

Encore une fois bien sûr oui, c'est simplement beaucoup moins guidé, beaucoup plus compliqué, et du moment où tu fais une solution «perso», tu ne bénéficieras jamais d'un support de la communauté. De plus développer à partir d'un support développé par d'autres, cela permet de ne pas avoir à le faire soi-même, quelle économie de temps (dont on manque cruellement) !

J'aimerai beaucoup que l'on m'explique les réels intérêts de ces outils appliqués à nos jeux. Avis aux courageux.

Un jeu est une application complexe, amenée à évoluer souvent et rapidement, et dont le chef de projet est généralement amateur et n'a donc que peu de temps, et peu de compétences pour sécuriser ou optimiser. Un framework répond à toutes ces contraintes. S'il y a bien un type de site qui a avantage à reposer sur un framework c'est bien un jeu par navigateur


Soyons honnêtes, les arguments pro-poo et pro-frameworks sont légion, les seules contraintes objectives et réellement pesantes sont qu'elles nécessitent un apprentissage, voire une remise en cause des acquis. C'est ce dernier point qui fait que beaucoup finissent par conclure que «ça sert à rien vot' truc» tout simplement parce qu'ils ne comprennent pas l'intérêt de changer de méthode alors que la leur fonctionne bien.
On comprend ces intérêts avec le temps.