Tu sais, comme le dis Boubou, avant les EJB 2.0 les serveurs d'applications faisait déjà souvent des appels locaux en interne, ce qu'a fait Sun c'est inclure cette possibilité dans la spec. Donc niveau perf, c'était déjà +- idem.
ha... je demande confirmation, tu as un lien?
Je ne trouve pas ça dérangeant d'avoir plusieurs classes par EJB, tu as les diverses interfaces implémentées (EJBHome, ...) et tu as l'implémentation proprement dite (qui est générée automatiquement). Effectivement ça bouffe de la mémoire, mais en contre partie ça rend pas mal de service.
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...
En plus les services rendus par le conteneur d'EJB, tu les as en utilisant des Session Beans, suffit de placer JDO (ou des DAO) derrière ces Session Beans, et tu rends ton modèle objet beaucoup plus simple, et tu diminues l'empreinte mémoire de ton application
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...
Par contre je ne comprends pas pourquoi tu te plains que le SQL soit généré tout seul dans les CMP (tu peux utiliser des BMP si tu veux), puis juste après tu te plains de devoir utiliser du SQL pour les finders ...
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... où est alors l'utilité des CMP je vous le demande... (par rapport aux BMP)
[^] # Re: Avantages ?
Posté par Guillaume Carre . En réponse à la dépêche JOnAS 3.1 est sortie. Évalué à 2.
Tu sais, comme le dis Boubou, avant les EJB 2.0 les serveurs d'applications faisait déjà souvent des appels locaux en interne, ce qu'a fait Sun c'est inclure cette possibilité dans la spec. Donc niveau perf, c'était déjà +- idem.
ha... je demande confirmation, tu as un lien?
Je ne trouve pas ça dérangeant d'avoir plusieurs classes par EJB, tu as les diverses interfaces implémentées (EJBHome, ...) et tu as l'implémentation proprement dite (qui est générée automatiquement). Effectivement ça bouffe de la mémoire, mais en contre partie ça rend pas mal de service.
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...
En plus les services rendus par le conteneur d'EJB, tu les as en utilisant des Session Beans, suffit de placer JDO (ou des DAO) derrière ces Session Beans, et tu rends ton modèle objet beaucoup plus simple, et tu diminues l'empreinte mémoire de ton application
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...
Par contre je ne comprends pas pourquoi tu te plains que le SQL soit généré tout seul dans les CMP (tu peux utiliser des BMP si tu veux), puis juste après tu te plains de devoir utiliser du SQL pour les finders ...
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... où est alors l'utilité des CMP je vous le demande... (par rapport aux BMP)
enfin on va pas refaire le gueguerre JDO vs CMP de serverside hein ;-)
http://www.theserverside.com/discussion/thread.jsp?thread_id=771&am(...)