Pratique, c'est pas faux, élégant, j'en suis moins sûr.
tu parles de l'IoC en elle meme ou de la facon dont spring le fait?
A quoi ca ressemblerait si c'etait dans le langage (ie sans workaround?) J'ai du mal a comprendre comment tu peux integrer ce concept au langage sans soit casser le decouplage offert par l'IoC, soit pourrir ta classe injectee avec des trucs sans rapport.
DIsons que le concept meme de l'IoC c'est de declare/effectuer les injections en dehors des classes concernees.
De meme, comment tu ferais pour gerer la distinction prototype/singleton (desole le terme est pas adapte ici, mais l'adapte ne me revient pas), avoir plusieurs instances des beans injectes etc?
Pour le cote usine a gaz, je te trouve tres dur avec spring.
Je connais pas webflow, donc je m'abstiendrais de commenter dessus.
Garde a l'esprit tout de meme que jee, spring et tout ces machins compliques, ca a un objectif: rendre des trucs tres complexes possible.
Pas rendre le dev web simple, pas etre simple a utiliser, juste rendre une enorme appli metier faisable.
Si tu veux qq chose de simple, jee n'est clairement pas le bon choix.
Donc ouais, ya plein de couches, c'est un peu le bordel, mais sans ca, ca serait un bordel bien plus grand a gerer.
En pratique, spring (en particulier) j'ai aucun reproche a lui faire, il m'injecte mes beans la ou je veux, ca me donne un point central pour les declarer, et vu comment l'appli devient touffue, je suis plutot content de declarer mes services/repository/assemblers de facon externe a l'appli, sans pour autant les transformer en singleton.
Pour ce qui est de devoir debugger dans les couches de spring, soit tu as rate qq chose, soit je comprends pas ce que tu veux dire. Ca doit etre le framework web le moins intrusif et qui gene le moins le debuggage que je connaisse. J'ai peut etre pas compris ce que tu veux dire cela dit.
Que tu préfère écrire des boucles de 20 lignes à la place d'un select * from truc where machin not in (select toto from dude) c'est ton problème.
???
On a le mapping de nos domain objects sur les objets eux meme via les annotations eeeeeet....
C'est tout.
@entity(table="plop")
@OneToMany(joinColumn="shaby")
@Column(bla)
etc.
On se prend parfois un peu la tete pour arriver a ecrire le mapping (mais bon, avec hibernate t'en chies un peu au debut, puis les meme pb reviennent, tu sais donc les resoudre et ca va vite au final).
On a un systeme de filter pour les recherches qui utilise HQL. Bref, la partie repository dans notre appli, c'est getFromId, saveOrUpdate, delete et 50 lignes de construction de requete HQL.
Apres que tu kiffes le SQL, ok, c'est ton droit le plus fondamental, mais quand tu vois la db purement comme une facon de persister ton graphe d'objet en ram, c'est agreable de ne (presque) pas y penser.
Tu aimes peut etre certes ca, c'est cool, mais dans la plupart des cas, une requete sql c'est juste "bon ben, db, tu prends toutes ces lignes la, et eventuellement tu me choppes les autres lignes dans cette table avec le meme id et aussi dans cette autre table, pis apres tu me tries ca comme ca. Merci". Les cas ou le sql est rellement interessant sont pas si courant, et la plupart du cas c'est juste du boiler plate bien relou.
Rajoutes par dessus la problematique du cache et celle de la mise a jour du graphe persiste a chaque modification, ca devient dur de trouver des arguments au SQL pur.
By the end of the day, tout ce que veut, c'est un set d'objet de toutes facons, donc etre oblige de passer par un langage pas du tout adapte aux objet pour ca, je trouve ca particulierement casse bonbons.
Et c'est vraiment ce qui me gene dans le sql avec les langages objet: t'introduis un paradigme relationnel qui n'a strictement rien a voir avec l'objet.
[^] # Re: Rien de transcendant dirait-on
Posté par thedude . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 1.
Pratique, c'est pas faux, élégant, j'en suis moins sûr.
tu parles de l'IoC en elle meme ou de la facon dont spring le fait?
A quoi ca ressemblerait si c'etait dans le langage (ie sans workaround?) J'ai du mal a comprendre comment tu peux integrer ce concept au langage sans soit casser le decouplage offert par l'IoC, soit pourrir ta classe injectee avec des trucs sans rapport.
DIsons que le concept meme de l'IoC c'est de declare/effectuer les injections en dehors des classes concernees.
De meme, comment tu ferais pour gerer la distinction prototype/singleton (desole le terme est pas adapte ici, mais l'adapte ne me revient pas), avoir plusieurs instances des beans injectes etc?
Pour le cote usine a gaz, je te trouve tres dur avec spring.
Je connais pas webflow, donc je m'abstiendrais de commenter dessus.
Garde a l'esprit tout de meme que jee, spring et tout ces machins compliques, ca a un objectif: rendre des trucs tres complexes possible.
Pas rendre le dev web simple, pas etre simple a utiliser, juste rendre une enorme appli metier faisable.
Si tu veux qq chose de simple, jee n'est clairement pas le bon choix.
Donc ouais, ya plein de couches, c'est un peu le bordel, mais sans ca, ca serait un bordel bien plus grand a gerer.
En pratique, spring (en particulier) j'ai aucun reproche a lui faire, il m'injecte mes beans la ou je veux, ca me donne un point central pour les declarer, et vu comment l'appli devient touffue, je suis plutot content de declarer mes services/repository/assemblers de facon externe a l'appli, sans pour autant les transformer en singleton.
Pour ce qui est de devoir debugger dans les couches de spring, soit tu as rate qq chose, soit je comprends pas ce que tu veux dire. Ca doit etre le framework web le moins intrusif et qui gene le moins le debuggage que je connaisse. J'ai peut etre pas compris ce que tu veux dire cela dit.
Que tu préfère écrire des boucles de 20 lignes à la place d'un select * from truc where machin not in (select toto from dude) c'est ton problème.
???
On a le mapping de nos domain objects sur les objets eux meme via les annotations eeeeeet....
C'est tout.
@entity(table="plop")
@OneToMany(joinColumn="shaby")
@Column(bla)
etc.
On se prend parfois un peu la tete pour arriver a ecrire le mapping (mais bon, avec hibernate t'en chies un peu au debut, puis les meme pb reviennent, tu sais donc les resoudre et ca va vite au final).
On a un systeme de filter pour les recherches qui utilise HQL. Bref, la partie repository dans notre appli, c'est getFromId, saveOrUpdate, delete et 50 lignes de construction de requete HQL.
Apres que tu kiffes le SQL, ok, c'est ton droit le plus fondamental, mais quand tu vois la db purement comme une facon de persister ton graphe d'objet en ram, c'est agreable de ne (presque) pas y penser.
Tu aimes peut etre certes ca, c'est cool, mais dans la plupart des cas, une requete sql c'est juste "bon ben, db, tu prends toutes ces lignes la, et eventuellement tu me choppes les autres lignes dans cette table avec le meme id et aussi dans cette autre table, pis apres tu me tries ca comme ca. Merci". Les cas ou le sql est rellement interessant sont pas si courant, et la plupart du cas c'est juste du boiler plate bien relou.
Rajoutes par dessus la problematique du cache et celle de la mise a jour du graphe persiste a chaque modification, ca devient dur de trouver des arguments au SQL pur.
By the end of the day, tout ce que veut, c'est un set d'objet de toutes facons, donc etre oblige de passer par un langage pas du tout adapte aux objet pour ca, je trouve ca particulierement casse bonbons.
Et c'est vraiment ce qui me gene dans le sql avec les langages objet: t'introduis un paradigme relationnel qui n'a strictement rien a voir avec l'objet.