D'abord, dés que je vois des mots tels que EJB, MVC, etc.. On sent les gars qui ont lu le manuel du parfait petit développeur (WEBSPHERE/TOMCAT/...).
J'ai travaillé en JSP et en PHP et je constate :
1 - aucune des 2 solutions peut faire du MVC correct (séparation du boulot d'infographiste/designer du html et du codeur) il arrivera toujours un moment ou il y a trop de code dans la page (pour la création de tableaux par exemple). A priori, PHP est un peu plus bordélique, sauf si on met toutes les fonctions dans un autre fichier importé.
2 - conséquence immédiate, j'ai vu trop de JSP qui ressemblait à du PHP -> gain nul en lisibilité, perte seche en facilité de développement.
3 - PHP n'a jamais été prévu pour faire tourner une usine à gaz, c'est orienté pour l'affichage d'une page et pas la succsession de plusieurs pages (comme le site SNCF par exemple).
4 - une appli PHP n'a pas besoin d'un environnement, un simple éditeur de texte suffit. C'est la robustesse du basic avec une syntaxe C.
5 - Trop souvent on passe des paramètres de pages en pages tout en refaisant le même traitement, ce qui supprime tous les avantages du JSP.
6 - Les applis JSP/EJB ont vite tendance à devenir des usines à gaz (en PHP aussi si les pages sont interdépendantes), on fait trop de traitement du côté JAVA, et pas assez du côté de la Base de Donnée (reqûete simple, et combinaison de plusieurs tables du côté de l'appli JAVA, au lieu de les faires en SQL).
Conclusion :
Perso, je trouve plus agréable de travailler en PHP (attention, j'ai pas dit que c'était mieux techniquement) car c'est bcp plus rapide pour développer, les libs sont vraiment orientés manipulations de texte et sgbd, et c'est pil-poil ce qu'il faut pour faire de l'affichage HTML.
Si maintenant il faut une appli qui aille ouvrir 36 sockets exotiques pour récupérer l'information, il vaut mieux utiliser JAVA, mais c'est plutôt une minorité de cas.
Et puis comme ça on a de bonnes excuses si ça foire.
Le problème de cette solution, c'est qu'elle est trop généraliste, et il faut prévoir pleins de trucs avant même de tapper le code de l'appli qui nous concerne.
Je ne crois pas au modéle de SUN (sur le plan technique, enfin en théorie c'est génial sisi, mais en pratique, quel bordel), mais il va quand même passer, parce que
1 - ça fait hype pour les gentils commerciaux
2 - donne plein de boulots aux SSII (Des usines à gaz tu écriras, pour faire payer la maintenance tu devras).
3 - fait plus sérieux qu'un logiciel dont les sources font 3mo et qui sont développés à la base par un gars indépendant
De toute manière, c'est toujours pareil, en fonction de l'appli à programmer, on va choisir l'une ou l'autre solution.
# Darkleon >Tout ça, c'est du marketing, concrétement qu'est-ce que ça donne.
Posté par Anonyme . En réponse à la dépêche Comparatif jsp/php. Évalué à 0.
J'ai travaillé en JSP et en PHP et je constate :
1 - aucune des 2 solutions peut faire du MVC correct (séparation du boulot d'infographiste/designer du html et du codeur) il arrivera toujours un moment ou il y a trop de code dans la page (pour la création de tableaux par exemple). A priori, PHP est un peu plus bordélique, sauf si on met toutes les fonctions dans un autre fichier importé.
2 - conséquence immédiate, j'ai vu trop de JSP qui ressemblait à du PHP -> gain nul en lisibilité, perte seche en facilité de développement.
3 - PHP n'a jamais été prévu pour faire tourner une usine à gaz, c'est orienté pour l'affichage d'une page et pas la succsession de plusieurs pages (comme le site SNCF par exemple).
4 - une appli PHP n'a pas besoin d'un environnement, un simple éditeur de texte suffit. C'est la robustesse du basic avec une syntaxe C.
5 - Trop souvent on passe des paramètres de pages en pages tout en refaisant le même traitement, ce qui supprime tous les avantages du JSP.
6 - Les applis JSP/EJB ont vite tendance à devenir des usines à gaz (en PHP aussi si les pages sont interdépendantes), on fait trop de traitement du côté JAVA, et pas assez du côté de la Base de Donnée (reqûete simple, et combinaison de plusieurs tables du côté de l'appli JAVA, au lieu de les faires en SQL).
Conclusion :
Perso, je trouve plus agréable de travailler en PHP (attention, j'ai pas dit que c'était mieux techniquement) car c'est bcp plus rapide pour développer, les libs sont vraiment orientés manipulations de texte et sgbd, et c'est pil-poil ce qu'il faut pour faire de l'affichage HTML.
Si maintenant il faut une appli qui aille ouvrir 36 sockets exotiques pour récupérer l'information, il vaut mieux utiliser JAVA, mais c'est plutôt une minorité de cas.
Et puis comme ça on a de bonnes excuses si ça foire.
Le problème de cette solution, c'est qu'elle est trop généraliste, et il faut prévoir pleins de trucs avant même de tapper le code de l'appli qui nous concerne.
Je ne crois pas au modéle de SUN (sur le plan technique, enfin en théorie c'est génial sisi, mais en pratique, quel bordel), mais il va quand même passer, parce que
1 - ça fait hype pour les gentils commerciaux
2 - donne plein de boulots aux SSII (Des usines à gaz tu écriras, pour faire payer la maintenance tu devras).
3 - fait plus sérieux qu'un logiciel dont les sources font 3mo et qui sont développés à la base par un gars indépendant
De toute manière, c'est toujours pareil, en fonction de l'appli à programmer, on va choisir l'une ou l'autre solution.
Darkleon (Cookies Lost in Space).