Plus tu factorises, modularises, mets en classe métier, plus ta performance diminue. Si je voulais faire du MVC, je ne ferais pas de php, il n'a pas été prévu pour ca.
Le php n'a pas plus, ni moins été prévu pour ça que Java ou ruby. Ce sont des frameworks (maison, ou généralistes) qui construisent sur le langage. Et un découpage simple MVC mais utile en PHP, ça se fait facilement. Evidemment, il ne faut pas attendre du PHP ce qu'on fait avec du Java...
Effectivement, il peut paraître mode et hype de faire des applications multi-plate-forme, multi-base, multi-serveur qui marchent quelque soient les serveurs utilisés, mais ce n'est pas ma tasse de thé. Ma vision est une applis, pour une tache, dans un environnement particulier.
Ce n'est pas une question de tasse de thé ou de hype.
C'est une question de gestion du cycle de vie total du logiciel. Si ton travail est destiné à être déployé sur un seul serveur, à un seul moment donné, tant mieux, c'est très bien aussi.
Mais certaine application doit avoir un cycle de vie long, où la plateforme sur laquelle elle repose changera régulièrement ; où elle sera déployée par des gens différents, aux compétences différentes, sur des architectures différentes. Si on voit à court terme, et qu'on peut se permettre de tout recoder, ou de patcher à tout va une appli au gré des changements de plateforme, très bien. Si on veut voir à plus long terme et sécuriser le plus possible les patches et les migrations, on prévoit un peu plus l'architecture de l'appli en fonction de ça.
La perte de performance, si elle reste minime par rapport à l'objet de l'application, peut être très bien balancée par le gain en organisation et en abstraction de l'appli. Ce n'est pas pour rien que l'on a plusieurs grosses applis web qui reposent sur différentes bases de données (MySQL, PostgreSQL, Sqlite, BDB, etc.).
- une applis ne doit pas migrer vers un serveur configuré différemment (on n'est pas au pays de la bidouille)
La bienvenue dans le monde réel ; le problème n'est pas qu'il ne faut pas faire ça, c'est évident ; le problème, c'est qu'on tombe inévitablement sur cas où ça a été fait ; et où le job est de gérer ce binz. Donc si on peut être proactif... (pour ceux qui suivront inévitablement) ça peut pas être plus mal. Théorie contre pratique.
- une applis ne change pas de base de donnée pour le fun.
Il ne s'agit pas de le faire pour le fun, il s'agit de faciliter, de façon stable et certaine, le déploiement sur plusieurs types de plateforme.
Effectivement, si le code-guideline de la maison c'est : multi plateforme, multi base de donnée, multi serveur (pourquoi pas multi-serveur configurations différentes?), configuration la plus large possible,cela change la manière dont est codée l'applis en question.
C'est bien de ce dont on parle.
Il faut bien voir qu'une application, ce n'est pas seulement des lignes de codes organisées, écrite une seule fois par un seul développeur. Il y a un cycle de vie qui peut être prévu long ou court, il y a des évolutions inévitables si celui-ci est long, et prévoir l'architecture et le développement de l'appli autour de cette idée peut, à terme, apporter de sérieux gains.
[^] # Re: Curiosité...
Posté par romain . En réponse au journal Offre d'emploi Développeur Web (Paris). Évalué à 4.
Ce n'est pas une question de tasse de thé ou de hype.
C'est une question de gestion du cycle de vie total du logiciel. Si ton travail est destiné à être déployé sur un seul serveur, à un seul moment donné, tant mieux, c'est très bien aussi.
Mais certaine application doit avoir un cycle de vie long, où la plateforme sur laquelle elle repose changera régulièrement ; où elle sera déployée par des gens différents, aux compétences différentes, sur des architectures différentes. Si on voit à court terme, et qu'on peut se permettre de tout recoder, ou de patcher à tout va une appli au gré des changements de plateforme, très bien. Si on veut voir à plus long terme et sécuriser le plus possible les patches et les migrations, on prévoit un peu plus l'architecture de l'appli en fonction de ça.
La perte de performance, si elle reste minime par rapport à l'objet de l'application, peut être très bien balancée par le gain en organisation et en abstraction de l'appli. Ce n'est pas pour rien que l'on a plusieurs grosses applis web qui reposent sur différentes bases de données (MySQL, PostgreSQL, Sqlite, BDB, etc.).
La bienvenue dans le monde réel ; le problème n'est pas qu'il ne faut pas faire ça, c'est évident ; le problème, c'est qu'on tombe inévitablement sur cas où ça a été fait ; et où le job est de gérer ce binz. Donc si on peut être proactif... (pour ceux qui suivront inévitablement) ça peut pas être plus mal. Théorie contre pratique.
Il ne s'agit pas de le faire pour le fun, il s'agit de faciliter, de façon stable et certaine, le déploiement sur plusieurs types de plateforme.
C'est bien de ce dont on parle.
Il faut bien voir qu'une application, ce n'est pas seulement des lignes de codes organisées, écrite une seule fois par un seul développeur. Il y a un cycle de vie qui peut être prévu long ou court, il y a des évolutions inévitables si celui-ci est long, et prévoir l'architecture et le développement de l'appli autour de cette idée peut, à terme, apporter de sérieux gains.