Disclaimer: Je fait du Java ou plutot du J2EE, et connais mal l'ecosysteme PHP, mais je doute fortement que ca soit tres different conceptuellement en PHP.
Une fois ceci dit, si je me trompe lourdement, je serais ravi qu'on me corrige.
Bref.
On peut prendre le probleme autrement aussi.
Il existe des outils qui vont:
- Simplifier enormement ton code (grosse diminution du code sql, gestion du pool de connexion etc.),
- Te rendre independant d'un quelconque SGBD,
- Te decharger d'une partie de la secu de ton appli (l'injection SQL, meme si ca se charge de facon manuelle, ca peut aussi se faire de facon automatique et c'est toujours ca de gagne)
- Potentiellement te faire gagner des perfs (cache d'objets, bon courage pour implementer ca a la main), ou en tout cas pas t'en faire perdre des masses.
Sachant que ces outil sont matures et fiables, quelle est la bonne raison objective de s'en passer?
Oui, on peut faire sans, mais on peut aussi faire avec, et ca apporte reellement toutes ces choses que j'ai citees plus haut, a un cout qui est derisoire.
C'est pas du babysitting comme tu le dis, c'est juste profiter d'un outil pour se decharger d'une part de travail ingrate pour se concentrer sur une partie plus interessante et utile du boulot (peaufiner le code metier et les features).
Mon boulot, c'est d'ecrire des applis metiers efficaces qui rendent le boulot des autres plus simples, pas de maintenir du sql ou de me prendre la tete avec des problemes purement techniques qui sont deja resolus par d'autres.
J'ai l'impression qu'on assiste au meme debat a chaque fois qu'on met au point une techno qui resoud des problemes purement techniques qui etaient inenvisageable qq annees auparavant.
C'etait pareil avec les compilos, avec les jvm, la memoire managee, les frameworks divers et variees, les IDE, que sais je encore.
Personnellement, un mec qui se pointe pour un entretien d'embauche et qui me sort ce genre de theories, il est recale d'office, et le reste de l'equipe pense pareil (et oui, ca nous est deja arrive, le mec etait recalcitrant a Spring, Hibernate et aux IDE).
[^] # Re: Journal très pertinent
Posté par thedude . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 3.
Une fois ceci dit, si je me trompe lourdement, je serais ravi qu'on me corrige.
Bref.
On peut prendre le probleme autrement aussi.
Il existe des outils qui vont:
- Simplifier enormement ton code (grosse diminution du code sql, gestion du pool de connexion etc.),
- Te rendre independant d'un quelconque SGBD,
- Te decharger d'une partie de la secu de ton appli (l'injection SQL, meme si ca se charge de facon manuelle, ca peut aussi se faire de facon automatique et c'est toujours ca de gagne)
- Potentiellement te faire gagner des perfs (cache d'objets, bon courage pour implementer ca a la main), ou en tout cas pas t'en faire perdre des masses.
Sachant que ces outil sont matures et fiables, quelle est la bonne raison objective de s'en passer?
Oui, on peut faire sans, mais on peut aussi faire avec, et ca apporte reellement toutes ces choses que j'ai citees plus haut, a un cout qui est derisoire.
C'est pas du babysitting comme tu le dis, c'est juste profiter d'un outil pour se decharger d'une part de travail ingrate pour se concentrer sur une partie plus interessante et utile du boulot (peaufiner le code metier et les features).
Mon boulot, c'est d'ecrire des applis metiers efficaces qui rendent le boulot des autres plus simples, pas de maintenir du sql ou de me prendre la tete avec des problemes purement techniques qui sont deja resolus par d'autres.
J'ai l'impression qu'on assiste au meme debat a chaque fois qu'on met au point une techno qui resoud des problemes purement techniques qui etaient inenvisageable qq annees auparavant.
C'etait pareil avec les compilos, avec les jvm, la memoire managee, les frameworks divers et variees, les IDE, que sais je encore.
Personnellement, un mec qui se pointe pour un entretien d'embauche et qui me sort ce genre de theories, il est recale d'office, et le reste de l'equipe pense pareil (et oui, ca nous est deja arrive, le mec etait recalcitrant a Spring, Hibernate et aux IDE).