Frameworks

[Sephi-Chan]

Définition:
Un framework est un espace de travail modulaire. C'est un ensemble de bibliothèques et de conventions permettant le développement rapide d'applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et facile à maintenir. Ces composants sont organisés pour être utilisés en interaction les uns avec les autres.


Le langage PHP est pourvu de différents frameworks.
Je pense qu'ouvrir un topic ou les gens pourront y présenter leurs questions, les points forts et les points faibles des frameworks qu'ils connaissent n'est pas du Luxe.
Enfin, la grande question: Pourquoi utiliser un framework? peut on l'utiliser pour un jeu?
Comme d'accoutumée, je reprendrais dans le sujet les messages les plus pertinents.

A vos plumes!

[naholyr]

Note que si jamais chainelongueetbizarre est connue par un moyen ou un autre, le système est cassé. Les probabilités sont certes faibles mais non nulles. Alors que le fait de refaire la requête (ou de les stocker en session si vraiment on est à 4 requêtes/session près) réduit la probabilité de modification des données à 0 (en ne considérant pas le piratage de la bdd ou du système de fichiers du serveur).

Quant à rajouter des couches, l'évolution des serveurs ne va pas dans le sens de ta prédiction Sephi-Chan Au contraire, plus on ajoute de couche et plus :
- on développe des éléments "atomiques" plus simples à débugger
- on peut aisément changer de système
La contre-partie étant évidemment la perte de performances.

Mais avec le temps, les performances des serveurs évoluent (la contre-partie n'est donc pas très grave), alors que le nombre de solutions augmentent dans chaque domaine (il est donc important de pouvoir changer indifféremment n'importe quelle brique de l'application), et les applications deviennent de plus en plus complexes (il est donc vital de les décomplexifier pour simplifier le débuggage).

Donc +1 pour les frameworks

[uriak]

On parle là bien de la manière de faire les choses, pas de l'utilisation d'outils, non ? Je ne sais pas comment se présente en pratique quelque chose comme symphony à vrai dire.

[joshua]

"symfony"
c'est magique, je t'assure

[uriak]

(orthographe, quand tu nous tiens...) Disons que j'ai toujours la crainte d'être débordé par le code qui n'est pas de ma main. Mais peut être que je m'en fais pour pas grand chose ^^

[joshua]

en fait symfony t'allege le code. C'et comme si on t'ajoutait un formalisme et des fonctions, mais ton code reste tient. Ca a l'air assez sympa, surtout que ca fait du MVC natif. J'ai acheté le bouqin et je potasse.....

[pascal]

je vois pas mal d'avantages :
_ plein de choses sont gérées de base : sécurité, sessions, accès à le DB, MVC, url rewriting, cache, logging, configuration, débuggage...
_ il existe des modules, pas besoin de tout recoder : espace membre, blog, CMS
_ on peut créer ses modules, et les réutiliser dans d'autres jeux
_ la structure du framework impose des régles, ça évite de partir en live
_ utiliser un framework, c'est utile sur un CV
_ on peut trouver beaucoup de doc, tutoriaux, forums sur les frameworks, au contraire des appli maison
_ on peut recruter des personnes qui l'utilisent déjà

et des inconvénients, aussi :
_ il faut se forcer à apprendre le fonctionnement du framework, le résultat n'est pas toujours immédiat
_ une petite perte de performances, à cause des différentes couches ( mais le cache existe )

personnellement, je potasse symfony depuis un mois et demi, je pense l'utiliser prochainement pour mes sites et un jeu.

A+

Pascal

[zzarbi]

Personnellement je trouve les frameworks en général un peu lourd pour nos jeux, qui ont souvent besoin d'optimisation...
La lenteur des framework ne vient pas que des couches, actuellement je code mon jeu en fesant "une sorte de framework" mais adapté à n'importe quel jeux, c'est à dire qu'une fois fini l'utiliser en framewokr standart sera fesable mais assez inutile.

Sinon l'énorme inconvénient c'est qu'il faut apprendre le fonctionnement du framework... Et bon nombre d'entreprise possède leur framework... Bon ça a tendance à changer vu que la moitié de ces entreprises se tournent finalement vers les solution avec une communeauté genre symfony...

[Sephi-Chan]

Quant à rajouter des couches, l'évolution des serveurs ne va pas dans le sens de ta prédiction Sephi-Chan Au contraire, plus on ajoute de couche et plus :
- on développe des éléments "atomiques" plus simples à débugger
- on peut aisément changer de système
La contre-partie étant évidemment la perte de performances.

Mais avec le temps, les performances des serveurs évoluent (la contre-partie n'est donc pas très grave), alors que le nombre de solutions augmentent dans chaque domaine (il est donc important de pouvoir changer indifféremment n'importe quelle brique de l'application), et les applications deviennent de plus en plus complexes (il est donc vital de les décomplexifier pour simplifier le débuggage).

Donc +1 pour les frameworks

Oui, tout ça est bien beau, simplifier les choses. Mais en a-t-on réellement besoin ?

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 ?

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 ?

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.

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


Sephi-Chan

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