Différence avec les JavaBeans

Bonjour,
Je realise actuellement une sorte de médiatheque ou je dois mêler jsp ac une base de données
On nous a conseillé d'utiliser les EJB pour assurer l'accès avec une base de données.
Par contre, je ne vois pas du tout où est la différence entre un java Bean "normal" et un EJB. Il paraît qu'on y gagne beaucoup..
SI quelqu'un pouvait m'expliquer la différence.. Merci d'avance

Un Java Bean est une classe "normal" il suffit pour cela que le developpeur ayant coder cette classe ai suivi certaine regle de developpement.
Les EJB font parti de J2EE ,il s'agit d'un java bean qui grace au serveur d'application dans lequel il est deployé sais faire BCP de chose , comme par exemple gestion de la persistence gestion des transaction (Bean Entity CMP), utilisation des EJB a distance (RMI) ... etc

Mais bon tu devrais pouvoir trouver des article ou meme des post sur ce forum qui t'expliquerons plus en detail la difference , mais sache que la difference est ENORME !!!:)

Moi j'ai jamais utilisé les EJB, mais c'est pas vraiment la technologie a la mode en ce moment , en tout cas il faut eviter de developper des EJB 2 qui sont lourd (grosse usine a gaz meme ) a priori il faut plutot s'interessé a la version 3 .

Bcp te dirons "utilise plutot Hibernate+Spring" !!

A toi de voir :wink:

Merci bien pour la réponse.
Mais par exemple maintenant, supposons que j'ai une base de donnée à une table toute simple, une table personne avec des attributs du genre nom, prenom etc...
Comment executer une requete sur la base de donnée. Est ce que je dois créer de requetes du genre avec des objets ResultSet tout comme dans un java Bean ou bien cela fonctionne t il autrement ? merci d'avance

Et bien un EJB entity CMP (COntainer Manage Persitence) gere lui meme la persitence (grace a des fichier de configuration) c'est a dire qu'il sais se charger ,se modifier et se creer sur le support de persistence en l'occurence une base de données relationnel .

Mais depuis les EJB il y a eu les framework de mapping objet/relationnel genre Hibernate/JDO qui sont plus optimiser et qui font la meme chose de façon plus legere !!

Le principe est d'associer une classe à une table et chaque attribut de ta classe un champ de la table , et tout cela dans un fichier de configuration.

En gros ces framework gere la parti persistence , tu n'as plus à coder avec JDBC et donc a utiliser ResultSet !!

Qui t'as conseiller l'usage d'EJB?
Je trouve ca super compliquer pour tes besoins.

EJB par rapport a Hibernate ou iBatis
+monté en charge (grace a l'as)
-complexité
-vitesse de devellopement

Je développe une médiathèque, c'est un projet de base de données.
Ok les EJB sont des objets que l'on peut appeler je veux bien, mais à part persistence cela fonctionne exactement comme des java Beans ou non ?
Merci d'(avance

Conseil de base, utiliser un DAO (Data Access Object) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public interface CommandeDAO { public Commande getCommandeById(Long id); public void saveCommande(Commande cde); ... }   public class CommandeDAOImpl implements CommandeDAO {   public Commande getCommandeById(Long id) { //tu utilises du JDBC directement ou tu utilises un framework plus évolué pour faire ta requete //si tu utilises JDBC directement, tu mappes le résultat dans un objet commande que tu retournes; Commande cde = new Commande(); cde.setId(resultset.get...); ... return cde; } ... }

---

Si tu souhaites changer l'implémentation, tu es libre de le faire et d'utiliser un implémentation tirant partie d'Hibernate, de Spring JDBC, iBatis, etc...(Entity Bean, mais la c'est une grosse betise).

Citation:

---

Envoyé par ze_key

EJB par rapport a Hibernate ou iBatis
+monté en charge (grace a l'as)

---

Ce n'est pas forcément vrai...

Citation:

---

ze_key a écrit:
EJB par rapport a Hibernate ou iBatis
+monté en charge (grace a l'as)
Ce n'est pas forcément vrai...

---

Comment tu fais avec hibernate pour separer physiquement (pour pouvoir ajouter des serveurs) la partie presentation de la partie business/db ?
A part un web service je vois pas.[/quote]

Citation:

---

Envoyé par ze_key

Comment tu fais avec hibernate pour separer physiquement (pour pouvoir ajouter des serveurs) la partie presentation de la partie business/db ?
A part un web service je vois pas.

---

Tu veux dire que tu utilises l'interface distante d'un EJB Entity ? Ca c'est une vrai fausse bonne idée !!! Les seuls EJB pouvant représenter un interet (en tout cas pour moi) sont les EJB Session stateless et les Message Driven Bean.

Et pourquoi ne pas multiplier le nombre de conteneurs de servlets sur lesquels tout est deployé ? Il suffit alors de ne pas charger trop sa session http et d'activer la réplication (si en mode round robin, pas nécessaire en sticky session)...

Le seul cas que je vois où il peut être interessant d'avoir plus de conteneurs d'EJB que de conteneurs de servlets est celui où il existe une grosse différence de charge entre les traitements dans les différents conteneurs (avec potentiellement des risques de gros plantage).

Nan nan moi les EJB je les fuis. Mais nous avons fait une étude sur l'utilitié d'utiliser des EJB (Qui entre parenthese nous a conduit à utiliser hibernate) et l'intérêt majeur était de permettre demultiplier les application serveur pour faire face à la charge online mais surtout la charge des batchs.
Et pour ce cas (mix batch/online) les EJB semblaient plus adaptés lors de la montée en charge mais cela ne nous à pas empeché d'utiliser hibernate pour les batch :wink: avec cependant le probleme de devoir deployer 2x les classes hibernate une fois sur le servlet engine et une fois sur la machine batch.

La création d'un ejb est apparemment compréhensible .
Mais admettons que j'ai 2 tables liées par exemple une personne qui a un item ac une table Personne et une table Item.
Personne possede Item comme attribu

Comment dire dans l'ejb personne qu'il possède un ejb item ?? Je me perds......

Citation:

---

Envoyé par ze_key

Qui t'as conseiller l'usage d'EJB?

---

gilles641 : peux tu répondre à cette question très importante ?

Si c'est un conseil, il est très mauvais.
Si c'est une contrainte, bonne chance.

C 'est un projet de base de données relationnel plus compliqué que tout celà, une médiatheque en ligne. Nous n'avons pas de notions des ejb mise à part 2 ou 3 slides de cours alors il est pas évident de comprendre le principe

Nous ce que l'on te conseille, c'est si tu n'as pas encore commencé et que EJB n'est pas une contrainte alors change l'archi et utilise hibernate/iBatis/JDO ce que tu veux mais pas des EJB car en autre probleme les EJB vont te forcer à prendre en main un serveur d'application tel que JBOSS/WEbsphere ou BEA mais c'est encore plus de chose à apprendre.

Nous nous utilisons avec succèes hibernate sur une appli qui support 800 users dont pres de 80 simultanés et qui process près de 300 000 trx bancaires/jour.

Je dois en fait , pour tester, utiliser une partie d'ejb et créer des javaBean à la main. Nous utilisons postgressql et resin, super non ?

Si tu dois utiliser des EJB :
- utilise les EJB sessions pour fournir une interface (coarse grain) d'accès à ton application (pas forcement une interface distante)
- utilise les pour une gestion déclarative des transactions
- utilise un objet standard auquel l'EJB déléguera le traitement métier (pas de code métier dans un EJB pour la testabilité)
- l'objet utilisé par ton EJB fera appel à un DAO pour gérer la persistance,
- n'utilises JAMAIS d'EJB Entity

Super en effet :?
Si y faut y faut. Sur le site de resin ils ont de très bon tutoriaux pour te faire la main avec les différents d'EJB.
http://www.caucho.com/resin-3.0/ejb/...ello/index.xtp