2008-12-31 22 views
3

Nous utilisons des beans entité EJB2.x avec BMP (bean managed persistence). Il semble que BMP n'est pas pris en charge dans EJB3. Nous avions voulu rester à jour et passer à l'EJB3. Est-ce que quelqu'un sait s'il existe des options BMP disponibles dans 3.0? De ce que je peux dire, en utilisant 3.0, tous les beans entité doivent utiliser JPA et par définition ORM. Il existe certaines options pour utiliser SQL natif, mais ce n'est encore qu'un moyen d'utiliser JPA pour implémenter ORM.Migration des beans entité BMP EJB2.x

Je ne savais pas s'il existait une autre approche EJB3 pour obtenir la même fonctionnalité qu'avec les beans entité BMP EJB2.x. Nous utilisons actuellement la méthode ejbStore standard pour mettre à jour la base de données via le SQL natif et la méthode ejbLoad pour rechercher tous les beans et pour actualiser le bean en cas d'annulation d'une transaction. Je pensais que vous pourriez être en mesure de le faire avec des haricots de session EJB3 mais je n'étais pas sûr.

Peut-être qu'au lieu de migrer vers les fèves EJB3, nous devrions migrer vers Spring.

+0

Spring et EJB3 ne sont pas nécessairement mutuellement exclusifs. De quelle partie du printemps parlez-vous? C'est un grand cadre, et vous n'êtes pas obligé d'utiliser tout cela en même temps. –

+2

Btw, nous utilisons aussi BMP 2.1, et je ressens votre douleur. Je pense que la raison pour laquelle vous avez du mal à trouver quelque chose de similaire dans une API moderne est que les gens ont réalisé que le codage manuel de SQL est une mauvaise idée lorsque nous avons de nombreuses bibliothèques ORM qui génèrent les requêtes de manière agnostique. il suffit de spécifier le dialecte db). –

Répondre

0

Si vous voulez vraiment coder manuellement le code SQL, optez pour les POJO et les DAO JDBC bruts. Mais c'est aussi peut-être l'occasion de repenser la façon dont vous faites les choses et d'adopter l'ORM/JPA.