Si je comprends bien, ce concept de bean permet (à la manière de Spring, désolé si je me répète mais c'est à peu près tout ce que je connait en la matière :) ) de rendre disponible un objet pour d'autres objets ? Apporte t'il quelque chose en plus ? De plus, tu fais référence aux EJB, JDO et hibernate, peut on les intégrer facilement ? »
Spring n'a inventé ni le bean ni l'AOP, personnellement je me suis initié à l'AOP avec le très bon livre de Renaud Pawlak , Jean-Philippe Retaillé & Lionel Seinturier : Programmation orientée aspect pour Java / J2EE.
N'ayant jamais utilisé Spring, je peux pas te faire une comparaison exhaustive des différences, car de mon point de vue, il n'apporte rien de nouveau (cependant j'avoue mon ignorance sur le sujet)
J'espère que parmi nos lecteurs ceux connaissant les deux environnements, pourront donner leur avis sur les avantages et inconvénients de chacun (de façon argumenté, pas de troll SVP) .
Mon but ici, n'est pas de démontrer la supériorité d'une approche par rapport à une autre, mais de proposer une alternative au développeur afin de l'amener à confronter les approches, à se poser les bonnes questions et enfin à éclairer d'un autre jour ses connaissances en programmation .
Nous avons un composant Hibernate fourni avec le framework permettant de récupérer une session. Nous avons fait des tests concluants de mise a jour de base de donné il y a plus d'un an, mais le bean est un peu en stand-by car nous n'avons pas les ressources suffisantes pour mener tous les projets de front. C'est pour cela que nous recherchons des contributeurs, y compris pour reprendre le projet/bean hibernate.... à bon entendeur....
Enfin, rien n'empêche les concepteurs de bean Azuki d'utiliser Spring au sein de leur composants (même si cela peut paraître bizzare). Ils peuvent ainsi utiliser Spring pour l'IoC ou l'integration avec les autres API et profiter egalement du framework Azuki (par exemple : la gestion avancé des threads et les evenements).
« Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup ! »
Tout a fait d'accord :-) Surtout que dans la réalité, le code AOP ne constitue qu'un minorité du code généré pour une application et l'on ne doit pas forcer l'ensemble des développeurs à maîtriser des concepts qui leur sont inutiles pour développer leur business service.
ok je comprend mieux parce que comme décrit rapidement sur le site ça n'avait pas l'air d'aporter grand chose aux Observers ... Concernant la remarque sur les threads, il est vrai que j'utilise plutôt spring en environnement web donc je n'avais pas vraiment saisi l'intérêt. En fait il est possible de spécifier simplement dans une conf que les méthodes de tel bean seront exécutées dans un thread séparé ?
Tout à fait, cela est paramétrable via le weaver (ou directement dans le fichier de config azuki.xml)
« Si c'est applicable (appliqué), cela présente un intérêt certain. Mais ici aussi , en quoi est-ce plus simple qu'avec spring ? (ok, je pousse un peu la, pour un mec qui a pas encore essayé le framework ! je te promets d'y regarder de plus prêt mais je peux pas résister à l'envie de poser des questions et de "chercher la ptite bête" ). »
C'est plus simple dans le sens que nous souhaitons que l'intégrateur ne s'occupe pas de l'implémentation du code mais seulement de la documentation et des annotations fourni avec les composants pour réaliser son tissage. Notre approche est que le composant doit rester une boite noire.
« Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;) »
Par exemple : Un composant peu initier deux traitements qui s'exécutent en parallèle, suite à la génération d'un événement par exemple. Le framework permet de créer un point de synchronisation, CaD de ne lancer l'exécution d'une troisième méthode que lorsque les deux précédentes sont terminées.
La encore , étant plutôt développeur web, ca ne me parle pas trop puisque j'ai l'impression que J2EE et spring me fournissent tout les contextes (avec les scopes appropriés) dont j'ai besoin pour stocker mes objets.
Encore une fois, rien ne t'empêche de continuer à utiliser Spring avec Azuki.
« PS: hors sujet, mais quelqu'un connaîtrait il un bon framework javascript en remplacement de dojo ? »
Nous utilisons pour nos dev une librairie basé sur GWT de google. Notre lib apporte quelques fonctions supplémentaires comme la gestion des Datasets et des tableaux de données coté client. Elle sera fournie à la rentrée (octobre?) avec la version 1.1 d'Azuki --> pas si hors sujet que cela ! :-)
[^] # Re: Reponses
Posté par Robert Bakic . En réponse à la dépêche Azuki recherche des contributeurs. Évalué à 5.
Spring n'a inventé ni le bean ni l'AOP, personnellement je me suis initié à l'AOP avec le très bon livre de Renaud Pawlak , Jean-Philippe Retaillé & Lionel Seinturier : Programmation orientée aspect pour Java / J2EE.
N'ayant jamais utilisé Spring, je peux pas te faire une comparaison exhaustive des différences, car de mon point de vue, il n'apporte rien de nouveau (cependant j'avoue mon ignorance sur le sujet)
J'espère que parmi nos lecteurs ceux connaissant les deux environnements, pourront donner leur avis sur les avantages et inconvénients de chacun (de façon argumenté, pas de troll SVP) .
Mon but ici, n'est pas de démontrer la supériorité d'une approche par rapport à une autre, mais de proposer une alternative au développeur afin de l'amener à confronter les approches, à se poser les bonnes questions et enfin à éclairer d'un autre jour ses connaissances en programmation .
Nous avons un composant Hibernate fourni avec le framework permettant de récupérer une session. Nous avons fait des tests concluants de mise a jour de base de donné il y a plus d'un an, mais le bean est un peu en stand-by car nous n'avons pas les ressources suffisantes pour mener tous les projets de front. C'est pour cela que nous recherchons des contributeurs, y compris pour reprendre le projet/bean hibernate.... à bon entendeur....
Enfin, rien n'empêche les concepteurs de bean Azuki d'utiliser Spring au sein de leur composants (même si cela peut paraître bizzare). Ils peuvent ainsi utiliser Spring pour l'IoC ou l'integration avec les autres API et profiter egalement du framework Azuki (par exemple : la gestion avancé des threads et les evenements).
« Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup ! »
Tout a fait d'accord :-) Surtout que dans la réalité, le code AOP ne constitue qu'un minorité du code généré pour une application et l'on ne doit pas forcer l'ensemble des développeurs à maîtriser des concepts qui leur sont inutiles pour développer leur business service.
ok je comprend mieux parce que comme décrit rapidement sur le site ça n'avait pas l'air d'aporter grand chose aux Observers ... Concernant la remarque sur les threads, il est vrai que j'utilise plutôt spring en environnement web donc je n'avais pas vraiment saisi l'intérêt. En fait il est possible de spécifier simplement dans une conf que les méthodes de tel bean seront exécutées dans un thread séparé ?
Tout à fait, cela est paramétrable via le weaver (ou directement dans le fichier de config azuki.xml)
« Si c'est applicable (appliqué), cela présente un intérêt certain. Mais ici aussi , en quoi est-ce plus simple qu'avec spring ? (ok, je pousse un peu la, pour un mec qui a pas encore essayé le framework ! je te promets d'y regarder de plus prêt mais je peux pas résister à l'envie de poser des questions et de "chercher la ptite bête" ). »
C'est plus simple dans le sens que nous souhaitons que l'intégrateur ne s'occupe pas de l'implémentation du code mais seulement de la documentation et des annotations fourni avec les composants pour réaliser son tissage. Notre approche est que le composant doit rester une boite noire.
« Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;) »
Par exemple : Un composant peu initier deux traitements qui s'exécutent en parallèle, suite à la génération d'un événement par exemple. Le framework permet de créer un point de synchronisation, CaD de ne lancer l'exécution d'une troisième méthode que lorsque les deux précédentes sont terminées.
La encore , étant plutôt développeur web, ca ne me parle pas trop puisque j'ai l'impression que J2EE et spring me fournissent tout les contextes (avec les scopes appropriés) dont j'ai besoin pour stocker mes objets.
Encore une fois, rien ne t'empêche de continuer à utiliser Spring avec Azuki.
« PS: hors sujet, mais quelqu'un connaîtrait il un bon framework javascript en remplacement de dojo ? »
Nous utilisons pour nos dev une librairie basé sur GWT de google. Notre lib apporte quelques fonctions supplémentaires comme la gestion des Datasets et des tableaux de données coté client. Elle sera fournie à la rentrée (octobre?) avec la version 1.1 d'Azuki --> pas si hors sujet que cela ! :-)