Pour les perfs voir les benchs déjà cités qui montrent que l'introduction de l'interface local ne change pas grand chose? D'autre part, Fleury a déjà dit dans plusieurs papiers et docs que JBoss optimise les appels locaux.
ha... moi avoir 4 ou 5 classes par objet métier, quand tu as un modèle de 300 objets, je trouve ca un peu génant... quand tu vois que tu n'en as qu'une à coder avec JDO...
Argh ! Utilise donc XDoclet, malheureux ! Une seule classe à coder par Bean. Faux vraiment être un troll pour coder ça à la main.
De toute façon, en pratique, tout le monde fait du Session Bean + JDBC, aprés s'être cassé les dents sur les Entity Beans...
Fleury dit exactement le contraire, et j'ai plutôt tendance à le croire lui, désolé.
je ne me plains pas que le SQL soit généré tout seul, je me plains que le SQL généré tout seul soit pourri... et qu'en conséquence on soit obligé de tout coder dans les finders...
[^] # Re: Avantages ?
Posté par boubou . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 1.
Pour les perfs voir les benchs déjà cités qui montrent que l'introduction de l'interface local ne change pas grand chose? D'autre part, Fleury a déjà dit dans plusieurs papiers et docs que JBoss optimise les appels locaux.
ha... moi avoir 4 ou 5 classes par objet métier, quand tu as un modèle de 300 objets, je trouve ca un peu génant... quand tu vois que tu n'en as qu'une à coder avec JDO...
Argh ! Utilise donc XDoclet, malheureux ! Une seule classe à coder par Bean. Faux vraiment être un troll pour coder ça à la main.
De toute façon, en pratique, tout le monde fait du Session Bean + JDBC, aprés s'être cassé les dents sur les Entity Beans...
Fleury dit exactement le contraire, et j'ai plutôt tendance à le croire lui, désolé.
je ne me plains pas que le SQL soit généré tout seul, je me plains que le SQL généré tout seul soit pourri... et qu'en conséquence on soit obligé de tout coder dans les finders...
Un exemple serait le bienvenu...