concernant spring, je suis pas trop d'accord.
C'est un framework fabuleux, admirablement bien ecrit, qui permet tout simplement de ne pas perdre de temps sur des betises techniques.
Faire une appli J2EE sans framework pour gerer la base de la base, c'est quand meme particulierement pete couille et tu perds un temps monstrueux pour faire des trucs qui n'ont rien a voir avec le code metier (ce que tu es paye pour ecrire, ne l'oublions pas).
Un peu comme hibernate: tout ce que je veux, c'est lui dire que tel objet va remplir ses attributs dans telle table.
Le sql resultant, je m'en cogne.
Trier les udpates (delete/update/add) quand je modifie une liste, ca me saoule et j'ai autre chose a faire.
Ecrire la requete de join, ca me gonfle, mais tu peux pas savoir a quel point. Les tables sont designes, on lui dit que tel objet a sa foreign key dans telle table, demerde toi tout seul mon gars, nous on est occupe a autre chose.
Gerer mon pool de connexion, itou.
Le probleme ici, c'est qu'il part de 0.
Le framework l'aide, mais le framework ne peut pas tout faire. Va falloir qu'il apprenne comment ca marche sous le capot, ca va lui permettre de comprendre les entrailles de son framework, ce qui va lui permettre de comprendre ce qu'il se passe quand il utilise son framework.
Bref, il passe de debutant a mec qui connait son affaire.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par thedude . En réponse au journal framework ou farmer ?. Évalué à 1.
C'est un framework fabuleux, admirablement bien ecrit, qui permet tout simplement de ne pas perdre de temps sur des betises techniques.
Faire une appli J2EE sans framework pour gerer la base de la base, c'est quand meme particulierement pete couille et tu perds un temps monstrueux pour faire des trucs qui n'ont rien a voir avec le code metier (ce que tu es paye pour ecrire, ne l'oublions pas).
Un peu comme hibernate: tout ce que je veux, c'est lui dire que tel objet va remplir ses attributs dans telle table.
Le sql resultant, je m'en cogne.
Trier les udpates (delete/update/add) quand je modifie une liste, ca me saoule et j'ai autre chose a faire.
Ecrire la requete de join, ca me gonfle, mais tu peux pas savoir a quel point. Les tables sont designes, on lui dit que tel objet a sa foreign key dans telle table, demerde toi tout seul mon gars, nous on est occupe a autre chose.
Gerer mon pool de connexion, itou.
Le probleme ici, c'est qu'il part de 0.
Le framework l'aide, mais le framework ne peut pas tout faire. Va falloir qu'il apprenne comment ca marche sous le capot, ca va lui permettre de comprendre les entrailles de son framework, ce qui va lui permettre de comprendre ce qu'il se passe quand il utilise son framework.
Bref, il passe de debutant a mec qui connait son affaire.