Je débute en conception JSP/servlet/Bean, et je me pose pas mal de questions dont la plus importante est : Quel est l'intérêt d'un bean ??    
 
J'ai un peu lu a gauche et à droite, et sincérement, je ne vois pas ses avantages..
Pour moi, le seul intérêt d'un bean était de pouvoir partager des données entres les différents JSP..
Mais on peut aussi utiliser une HtppSession bien plus pratique car accessible aussi dans les Servlets...
 
Je ne me sers de bean que pour appeler des méthodes statiques et basta..    
 
Je suis totalement perdu, j'aimerai donc avoir l'avis de diverses personnes sur ce qu'est un bean réellement et comment bien l'utiliser...
 
D'avance merci...
   
                Dephi
 
 
Ps : en fait, le seul intérêt d'un bean pour moi C lorsque ce bean est au niveau applicatif... mais sinon...  

 
Représenter un objet business et te permettre d'avoir une représenttation abstraite de cet objet (ie fournir des interfaces d'accès publiques te permettant de modifier la structure interne si ca te change).
 

 
Tu ne trouves pas que d'attacher un bean qui représente un client c'est bcp plus propre que d'attacher une String id, une String nom, une String prénom, etc dans la session ?  
 

 
Un bean n'a pas de méthodes statiques logiquement (tu ne confonds pas avec un EJB par hasard ? et plus particulièrement sa home interface?
 
 

Avant tout merci de tes précisions..  
Mais j'ai encore besoin d'eclaircissements..    
 
 

Qu'entends tu exactement par "interface" ??
Interface au sens Java pur ou bien en temps que classe avec get et set (type "proxy" )
 

Là je suis entièrement d'accord avec toi..
Mais quel intérêt d'attacher un bean plutot que d'attacher une classe à la session ???
 
 
 

En fait je voulais dire que pour moi (à l'heure actuelle) le seul intérêt d'un bean par rapport à un object stocké en  session est la "portée" du bean qui peut-être gérée au niveau applicatif..
 
Et dans ce cas-là, peux t'on récuprérer un bean dans des servlets ????
 
 
 
Merciiiiii !!!
     
   

Yep,
 
réponse à tes questions:
 

 
 
Ouais non en fait je voulais dire "proxy" et pas interface au sens stricto sensu. En gros tu peux changer la représentation interne (par exemple si tu stockes tes clients dans un fichier texte puis que tu change par du XML ou une BD tu dois rien changer d'autre.
 

 
Bin un bean c'est une classe déjà (enfin tu vois ce que je veux dire). En gros la définition d'un bean est une classe spécialisée permettant à représenter un concept. Je dirai que c'est un collecteur d'info sur un objet. Avoir un bean client prend donc ici tout son sens.
 

 
Je dirai que 99% du temps où j'utilise un bean c'est dans le contexte d'une servlet. Donc OUI
 
   

[citation][nom]DarkLord a écrit[/nom]Yep,
 
réponse à tes questions:
 

Ca C un mec cool qui réponds très vite en plus..
   
Encore    
 
 

On parle le même language now, on se comprends et on est d'accord...
   
 

C toujours là où je bloque (enfin, on est 2 à bloquer derrière l'ecran..)
Je pige toujours pas la différence entre :
 
 
<> le bean client :
je l'instancie via jsp:useBean
et je le récupère via :
session.getAttribute("nom_du_bean" );
 
 
<> la classe client :
Je l'ajoute simplement a ma session et zou, quand j'en ai besoin, je fais un  
Client c = (Client)session.getAttribute("client" );
 
 
...........................
Bon, on vient de faire des essais et je crois que j'ai enfin compris comment ca marchait..
D'apres ce que je pige, le seul intérêt C de pouvoir se servir des "jsp:useBean" dans les jsp..
Un bean C donc encore un terme pompeu en informatique pour representer.. bah pas grand chose de plus qu'une classe...    
(où j'ai encore loupé une étape..)  

c'est une classe spécialisée. Tout comme une classe qui implémente Runnable est une classe spécialisée dans le sens où elle représente un thread, tout comme une classe qui étends HttpServlet est spécialisée dans le sens où c'est une servlet qui fonctionne via HTTP, etc etc.
 
Tu as les classes Java et un certain nombres de spécialisations. Donc je ne dirai pas que c'est un terme pompeux. La seule chose que je regrette c'est les notions de JavaBeans et de Enterprise JavaBeans qui n'ont pas grand chose à voir l'une avec l'autre.
 
Bref. Pour conclure je dirai que c'est une question de design. Lorsque tu fais jsp:useBean tu peux très bien récupérer une classe qui n'étends pas java.beans.Bean et qui donc n'est pas un bean stricto sensu.
 
Mais bon ca c'est une autre histoire.