1) Les Azuki bean ne sont pas destinés à encapsuler les ...
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 ?
2) Ses differentes vues permettent de s'abstraire du fichier de tissage en donnant une vue d'ensemble de la structure de l'application.
Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup !
3) et 4) : 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é ?
Dans l'approche Azuki, les spécialistes techniques travaillent sur leur propres beans qui sont pour la plupart de type "Aspect". Les developpeurs produit codent les beans de type "Business Service". Les équipes projets tissent l'application finale qui sera installée chez le client en remplaçant certain "Business Service" par des beans spécifiques
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" ).
- Chaîner des traitements en créant des points de synchronisation.... etc...
Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;)
5) 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.
En tout cas, merci pour tes réponses : tu m'a au moins convaincu d'essayer par moi même. Bon, pas tout de suite vu qu'entre les projets pro et perso j' ai du pain sur la planche mais bon ...
PS: hors sujet, mais quelqu'un connaitrait il un bon framework javascript en remplacement de dojo ?
[^] # Re: Reponses
Posté par gazbhan . En réponse à la dépêche Azuki recherche des contributeurs. Évalué à 4.
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 ?
Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup !
3) et 4) : 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é ?
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" ).
Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;)
5) 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.
En tout cas, merci pour tes réponses : tu m'a au moins convaincu d'essayer par moi même. Bon, pas tout de suite vu qu'entre les projets pro et perso j' ai du pain sur la planche mais bon ...
PS: hors sujet, mais quelqu'un connaitrait il un bon framework javascript en remplacement de dojo ?