L'architecture MVC, il y a quelques temps (quelques années) un membre de l'équipe ne jurait que par ça et pour lui c'était évident qu'il fallait adopter ce type d'architecture. Il a fait un prototype tout simple pour voir ce que ça donnait avant de lancer le gros chantier. Résultat sans appel : une catastrophe en terme de performances. La page était entre 5 et 10 fois plus longue à générer côté serveur. Il a tenté ce qu'il pouvait pour améliorer les performances, mais il est arrivé à la conclusion qu'on ne pouvait pas rivaliser en terme de performances avec du code moins "abstrait" (avec moins de couches). Et ce projet et assez vite retourné dans les cartons.
Evidemment, on peut me répondre qu'il s'y est mal pris, qu'il n'a pas pris la bonne lib, qu'il faut réessayer en 2011. Sans aucun doute. Mais je ne vois pas bien ce que cela peut nous apporter. Piwigo est très performant, plutôt facile à maintenir et à étendre. L'ajout de couche pourrait rapidement rendre le tout ingérable.
Donc pour moi, séparer le "métier" et "l'accès aux données", je comprends l'intérêt mais je n'applique pas sur Piwigo. Par contre, on a clairement séparé le "métier" et la génération du HTML. On utilise Smarty pour cela. C'est plus propre et plus performant que la génération de HTML directement depuis le PHP.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par Pierrick Le Gall . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 4.
L'architecture MVC, il y a quelques temps (quelques années) un membre de l'équipe ne jurait que par ça et pour lui c'était évident qu'il fallait adopter ce type d'architecture. Il a fait un prototype tout simple pour voir ce que ça donnait avant de lancer le gros chantier. Résultat sans appel : une catastrophe en terme de performances. La page était entre 5 et 10 fois plus longue à générer côté serveur. Il a tenté ce qu'il pouvait pour améliorer les performances, mais il est arrivé à la conclusion qu'on ne pouvait pas rivaliser en terme de performances avec du code moins "abstrait" (avec moins de couches). Et ce projet et assez vite retourné dans les cartons.
Evidemment, on peut me répondre qu'il s'y est mal pris, qu'il n'a pas pris la bonne lib, qu'il faut réessayer en 2011. Sans aucun doute. Mais je ne vois pas bien ce que cela peut nous apporter. Piwigo est très performant, plutôt facile à maintenir et à étendre. L'ajout de couche pourrait rapidement rendre le tout ingérable.
Donc pour moi, séparer le "métier" et "l'accès aux données", je comprends l'intérêt mais je n'applique pas sur Piwigo. Par contre, on a clairement séparé le "métier" et la génération du HTML. On utilise Smarty pour cela. C'est plus propre et plus performant que la génération de HTML directement depuis le PHP.