Comment mettre en place une architecture MVC ?

[pascal]

ha la la, on tire encore sur la POO ... c'est pratique à l'usage, compris pour un "petit ite web en PHP.

j'en parle ici : http://swroe.free.fr/dokuwiki/doku.php?id=tutoriaux

A+

Pascal

[Roworll]

Intéressant ces remarques sur les .tpl.

En fait avec mes trucs en XSLT, c'est la même chose en gros.
Je fournis via PHP des données brutes mais au lieu de les exploiter par .tpl, je le traite dans mon fichier XSL.

En ce qui concerne la POO, je ne nie pas l'utilité mais j'ai quelques petits soucis avec.

Le premier est conceptuel. J'ai beaucoup de mal à modéliser des objets viables et/ou interessants pour mon projet et je fini souvent par retourner au procédural.

Le deuxième concerne la charge pour PHP. Petite comparaison pratique.
Entre une méthode de connection aux BDD classique qui tient en une 10aine de ligne et une bonne classe bien montée (comme celles présentées ici avec classe de base + classe héritée pour MySQL) on atteint au bas mot une bonne centaine de lignes. Ok pour le gain sur la souplesse de programmation mais quid des ressources de la machine ?

Le troisième est un mélange des deux premiers. Imaginons une classe 'Vaisseau Spatial'
Elle a des méthodes pour l'attaque, le déplacement, la réparation, etc.
Idéologiquement, ça me gène de me dire que lorsque je déplace le vaisseau, PhP va charger toutes les méthodes pour l'attaque et la réparation alors qu'elles ne serviront pas.
Si je souhaite faire la même chose en procédural, j'ai un fichier à inclure pour charger les données du vaisseau, un fichier à inclure si je veux me déplacer, un fichier à inclure pour l'attaque, etc et donc, je charge moins de code "inutile".

Peut être que je me gourre dans mon approche mais ça m'interpelle pas mal quand même comme soucis.

[naholyr]

Le deuxième concerne la charge pour PHP. Petite comparaison pratique.
Entre une méthode de connection aux BDD classique qui tient en une 10aine de ligne et une bonne classe bien montée (comme celles présentées ici avec classe de base + classe héritée pour MySQL) on atteint au bas mot une bonne centaine de lignes. Ok pour le gain sur la souplesse de programmation mais quid des ressources de la machine ?

Franchement ? En PHP5+ ? Quasiment aucune différence.

Le troisième est un mélange des deux premiers. Imaginons une classe 'Vaisseau Spatial'
Elle a des méthodes pour l'attaque, le déplacement, la réparation, etc.
Idéologiquement, ça me gène de me dire que lorsque je déplace le vaisseau, PhP va charger toutes les méthodes pour l'attaque et la réparation alors qu'elles ne serviront pas.

Si tu as un fichier "fonctions.php" avec tout un tas de fonctions dedans, il va toutes les charger aussi...
Le "poids" d'un objet ne dépend pas du nombre de ses méthodes, mais de ses attributs d'instance.

Si je souhaite faire la même chose en procédural, j'ai un fichier à inclure pour charger les données du vaisseau, un fichier à inclure si je veux me déplacer, un fichier à inclure pour l'attaque, etc et donc, je charge moins de code "inutile".

Ouais mais paye tes milliers de fichiers et retrouve-toi là-dedans 6 mois plus tard :lol:
Et va documenter ça si tu veux un jour intégrer quelqu'un dans ton équipe... Il faut être encore plus discipliné quand on a une organisation procédurale, sinon c'est rapidement le foutoir. Bien sûr du procédural peut rester propre, mais c'est juste plus dur. Et ceux qui font l'effort de s'auto-discipliner fermement penchent rapidement vers la POO qui offre tous les outils nécessaire à la clarification du code, d'où cet "engouement".

[joshua]

La POO met en avant la portabilité et la clarté du code. Elle permet aussi la réusabilité.
Je pense qu'au final, le code étant plus propre il est moins bugué, et on compense par la fiabilité la légère perte de temps occasionnée par le surplus de code.

[Loetheri]

Si tu as un fichier "fonctions.php" avec tout un tas de fonctions dedans, il va toutes les charger aussi...
Le "poids" d'un objet ne dépend pas du nombre de ses méthodes, mais de ses attributs d'instance.

Pas forcément. Si tu crées une classe avec déplacement, combat, prolifération, ..., tu chargeras tout le fichier. Si tu crées un fichier par situation (car en général, tu n'attaques pas quelqu'un en bougeant et en réparant ton vaisseau), tu ne chargera qu'une partie.

Il s'agit donc d'une question d'organisation

Ouais mais paye tes milliers de fichiers et retrouve-toi là-dedans 6 mois plus tard :lol:

On rigole ? Quand tu as 3000 lignes de code pour un objet, merci bien. Mais tu rigoleras moins quand tu ne sais plus si c'est à la 800ième ligne ou à la 1050 ligne de code ... Comme je l'ai dit plus haut, c'est une question d'organisation. Personnellement, je préfère ranger mes cours dans plusieurs fardes que dans une grosse farde.

Et va documenter ça si tu veux un jour intégrer quelqu'un dans ton équipe... Il faut être encore plus discipliné quand on a une organisation procédurale, sinon c'est rapidement le foutoir.

Euh ... C'est encore une blague. Je me demande comment tu commentes ton code. Avoir un code procédural bien commenté n'est pas une abération. D'ailleurs, objet ne veut pas dire bien commenté. Il s'agit de part et d'autre d'une conscience des choses bien faites.

Bien sûr du procédural peut rester propre, mais c'est juste plus dur. Et ceux qui font l'effort de s'auto-discipliner fermement penchent rapidement vers la POO qui offre tous les outils nécessaire à la clarification du code, d'où cet "engouement".

Alors je suis une exception à la règle. Je travaille sur PHP, Java et j'ai eu l'occassion de toucher à Python. Autant en Java, les applications peuvent vite devenir complexe d'où une réelle utilité de l'objet, autant en PHP, ce n'est pas le but premier du langage; l'objet n'est réellement applicable que dans des applications utilisant, à mes yeux, une interactivité hors rechargement de page.

Mais il faut croire que je suis le seul programmeur sur ce forum à avoir une vision dans la lignée de son inventeur.

[Sephi-Chan]

Tu code dont de façon procédurale quand tu utilises PHP ?

Tu parles du rechargement de page, je pense justement que l'objet est pénible à utiliser car outre le fait de prévoir l'utilisation de l'objet pour une bonne modélisation, tu dois prévoir les interactions page/page, vu qu'une application PHP n'est pas un bloc unique.


Sephi-Chan

[Loetheri]

Je code de façon procédurale en PHP. C'est, à mes yeux, la seule manière de faire les choses correctement et logiquement.

l'objet n'est réellement applicable que dans des applications utilisant, à mes yeux, une interactivité hors rechargement de page.

Quand je dis ceci, je dis bien que l'objet n'a de sens que si on peut jouer avec l'objet sans recharger la page (en utilisant par exemple AJAX). Si à chaque changement de page, tu réinitialises un objet, celui-ci perd tout son sens. L'avantage d'un objet est entre autre la continuité de celui-ci.

Si quelqu'un crée un langage comme PHP mais avec possibilité de garder des données sur le serveur en fonction de l'utilisateur (garder un objet en mémoire par exemple), là, oui, l'objet aurait son sens. Mais nous ne sommes pas là. C'est l'utilisateur qui garde les données.

[naholyr]

Tu parles du rechargement de page, je pense justement que l'objet est pénible à utiliser car outre le fait de prévoir l'utilisation de l'objet pour une bonne modélisation, tu dois prévoir les interactions page/page, vu qu'une application PHP n'est pas un bloc unique.

À moins de faire de la persistance de données avec des librairies comme ezPDO, no query but persistance

[Caribou]

Milliers de fichiers lol, pour un pauvre jeu php ça me parait un peu exagéré moi quand meme, mais je comprend que c'était juste une façon de parler.

Pour moi c'est surtout une question de besoin pour ton projet, je sais pas pour imager, si ta une roue crever à ta bagnole, pour la changer tu as le choix entre le cric avec une clef en croix ou alors deux verrins pour soulever et un etablis à l'outillage impressionnant, c'est un peu comme ça que je compare dans ma tête Procédural* et POO, dans ce cas je prend mon cric, lol ok c'est pourri.
Euh sinon je vois aussi pour la POO, je me dis que si tu as beaucoup d'outils dans ton garage
tu vois un gros stock, ca traine un peu partout dans des boites ou cartons ou sac.. ta besoin d'un outil tu cherches pendant trois plombes, tu as trop d'outils en faite, là un bel etablis pour tout bien ranger et mettre en evidence ce serait bien pratique, et quand tu as besoin de faire un truc tu t'y retrouves facilement, c'est comme ça que je vois l'utilité de la POO.
Mais bon dans mon cas j'ai que quelques tournevis, une pince et un marteau... ben je met tout ça dans un tiroir et puis voila ça me suffit finalement (Procédural).

Bon ouai j'aime bien faire des comparaisons à la con :good:

[pascal]

pour reprendre l'exemple de la roue :

en procédural, on va faire des fonctions, genre :
_ demonterRoue( $diametre )
_ changerPneu( $typeGomme )
_ gonflerPneu( $pression, $diametre )

avec les infos sur la roue :
_ diamètre
_ pression
_ type de gomme
_ ...

on ballade plein de paramètres, toujours dans le même thème ( la roue ) pour utiliser ces fonctions.

alors on peut passer un tableau en paramètre :
_ demonterRoue( $roue )
_ changerPneu( $roue )
_ gonflerPneu( $roue )

avec $roue = array( 'diametre'=>22, 'pression'=>15, 'typeGomme'=>'dure');

ce qui facilite la vie, niveau écriture.

dans ce cas, autant passer à l'objet, ce qui donne :
$roue->changerPneu();

rien que par ça, le code est plus structuré, plus facile à écrire : on n'est pas embêté par une liste de paramètres.

à partir de là, on peut écrire de l'objet tout simple, ou s'y intéresser et aborder la composition ( des objets dans des objets ), l'héritage ( des objets enrichis ) et les design patterns ( des objets organisés entre eux via des modèles ).

A+

Pascal