J'ai l'impression qu'on reprend les mêmes problèmes mais au lieu de construire une grande solution toute faite et qui se voudrait tout terrain (à la EJB), on reprend avec les bases du langage (POJO) et on construit de petites solutions ciblées : jdo/Hibernate pour la persistence, Struts/webwork/tapestry pour les vues... et un framework d'application (pico Container, Spring) pour relier le tout.
Tant mieux, parce que moi, la solution J2EE/EJB ne m'a pas du tout séduit : à chaque fois que j'ai eu des EJBs sous les yeux, j'ai trouvé que c'était nettement trop complexe pour le besoin exprimé. En fait, c'est bien simple, je n'ai jamais vu de cas où ça se justifiait.
ça amène d'un part à des solutions plus simples à construire et à appréhender.
Ca n'est pas non plus systématique. Une solution super-classe à base d'IoC pourra être particulièrement complexe à comprendre, pour le débutant, meêm si elle présentera bien plus d'élégance.
Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
Et c'est justement ça qui est pour nous évident, alors que pour d'autres il est incompréhensible de faire la séparation. Il y a encore un rude travail d'éducation à faire.
Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
Mais pourquoi utiliser un framework pour faire ça ? C'est la grosse question que je me pose à propos de l'IoC. Effectivement, c'est très bien dans le concept, mais je ne vois pas pourquoi je vais passer par l'un ou l'autre pour recâbler mon appli.
Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
Je demande quand même à voir. Tout programme cache dans ses entrailles une bonne dose de dépendances non inversées (ou complexité cyclomatique, tant qu'on y est à utiliser des termes de barbares), et les enlever ne mérite parfois pas l'effort qu'on y fournit.
Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
Oui, enfin, la doctrine KISS, ça fait un bout de temps que ça devrait être le livre de chevet des développeurs Java, même si en réalité ça n'est pas le cas, et de loin.
Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
Pas pour les DBAs ;-)
Là où un programme d'avant gérait lui-même sa charge par une espèce d'effet domino rigolo, le programme moderne risque fort de beaucoup plus charger (notamment dans le cas d'un mapping O/R), et de faire s'affoler inutilement le DBA (je l'ai vu encore tout récement). Et le problème, dans ce cas-là, c'est quon considère encore la base comme plus importante que le logiciel (un blasphème, à mon sens, mais bon ...).
Donc, oui, je pensais aussi à l' IoC :-)
Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
En fait, le SOA, j'ai bien l'impression que ça permet de vendre plus de webservice, alors même que mon esprit orienté performance me sussure que les webservices sont au service d'une contreperformance évidente. mais bon, ça fait plaisir aux dicaïdors pressés ...
[^] # Re: Hasta la revolucion..
Posté par Nicolas Delsaux . En réponse à la dépêche Brèves Java. Évalué à 2.
Tant mieux, parce que moi, la solution J2EE/EJB ne m'a pas du tout séduit : à chaque fois que j'ai eu des EJBs sous les yeux, j'ai trouvé que c'était nettement trop complexe pour le besoin exprimé. En fait, c'est bien simple, je n'ai jamais vu de cas où ça se justifiait.
ça amène d'un part à des solutions plus simples à construire et à appréhender.
Ca n'est pas non plus systématique. Une solution super-classe à base d'IoC pourra être particulièrement complexe à comprendre, pour le débutant, meêm si elle présentera bien plus d'élégance.
Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
Et c'est justement ça qui est pour nous évident, alors que pour d'autres il est incompréhensible de faire la séparation. Il y a encore un rude travail d'éducation à faire.
Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
Mais pourquoi utiliser un framework pour faire ça ? C'est la grosse question que je me pose à propos de l'IoC. Effectivement, c'est très bien dans le concept, mais je ne vois pas pourquoi je vais passer par l'un ou l'autre pour recâbler mon appli.
Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
Je demande quand même à voir. Tout programme cache dans ses entrailles une bonne dose de dépendances non inversées (ou complexité cyclomatique, tant qu'on y est à utiliser des termes de barbares), et les enlever ne mérite parfois pas l'effort qu'on y fournit.
Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
Oui, enfin, la doctrine KISS, ça fait un bout de temps que ça devrait être le livre de chevet des développeurs Java, même si en réalité ça n'est pas le cas, et de loin.
Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
Pas pour les DBAs ;-)
Là où un programme d'avant gérait lui-même sa charge par une espèce d'effet domino rigolo, le programme moderne risque fort de beaucoup plus charger (notamment dans le cas d'un mapping O/R), et de faire s'affoler inutilement le DBA (je l'ai vu encore tout récement). Et le problème, dans ce cas-là, c'est quon considère encore la base comme plus importante que le logiciel (un blasphème, à mon sens, mais bon ...).
Donc, oui, je pensais aussi à l' IoC :-)
Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
En fait, le SOA, j'ai bien l'impression que ça permet de vendre plus de webservice, alors même que mon esprit orienté performance me sussure que les webservices sont au service d'une contreperformance évidente. mais bon, ça fait plaisir aux dicaïdors pressés ...