EJB
(entity local + CMP2.0/CMR) et JDO s'affrontent sur le terrain du mapping objet
relationnel ;
Eric>>>>>Les Entity Beans proposent un mod�le de
composants � forte granularit�.
La couche de
persistance est tr�s orient�e SGBDR et limit�e au mod�le de composant, rien de
tr�s objet donc.
JDO propose une
couche persistance au niveau de Java (donc granularit� fine), utilisable dans
tous les contextes java (J2ME, client-serveur J2SE et J2EE).
JDO est �galement
ind�pendant de la source de donn�es qui peut-�tre du relationnel ou tout autre
chose.
Enfin JDO
supporte tout java (h�ritage, polymorphisme).
Donc ce sont
plut�t 2 approches compl�mentaires, et non concurrentes.
Ni EJB, ni JDO ne r�pondent correctement � la notion de query. A la rigueur, les EJB sont mieux plac�s puisqu'on peut pr�d�finir des requ�tes SQL dans les descripteurs : au moins on sait ce qu'on fait car une bonne requ�te SQL bien d�finie est toujours la meilleure amie des performances. J'ai test� JBoss sur ce point, et franchement cela me convient.EJB et JDO disposent tous 2 d'un langage de requ�te et tous les 2 donnent acc�s � du SQL sous-jacent.Qu'entends-tu plus pr�cis�ment par "une r�ponse correcte � la notion de Query" ?Les transactions de JDO ont-elles la m�me s�mantique que ces des EJB?Eric>>>>>Dans un serveur d'applications les transactions JDO sont pilot�es par les transactions du serveur d'applications (en fait JDO s'int�gre dans un serveur d'App. � travers le standard JCA).======================================================Finalement, de quoi a-t-on besoin :De pouvoir remonter des graphes d'objets "intelligemment". Parce que sinon, autant remonter un paquet d'objets s�rialis� dans un SGBD. JDO, EJB Entity?Eric>>>>>C'est tr�s vrai, mais aujourd'hui aucun standard ne propose �� :-(Chez LIBeLIS nous travaillons actuellement sur une solution de ce type, qui permettra d'externaliser les d�finitions de graphes d'objets de fa�on externe � l'application par l'utilisation de use cases.De suivre des relations qui ne sont pas forc�ment calqu�e sur la jointure de 2 tables.Eric>>>>JDO permet cela.De pouvoir r�utiliser sans trop de peur un sch�ma relationnel d�j� existant : JDO ne r�pond pas � cela dans la spec que j'ai vu, et les EJB sont un peu simplistes (cf point pr�c�dent)Eric>>>>JDO supporte cela, c'est le mode "application ID".De d�finir le "business logic" dans des unit�s autonomes et ind�pendantes. EJB Session stateless (� la rigueur stateful pour des transactions plus longues) r�pond � cette probl�matique.Eric>>>>Effectivement personne ne songe � remettre en cause l'int�r�t des Session Beans, qui apportent beaucoup de services.
