> C'est une bonne idee mais une mauvaise implementation :-) > > Tu ne devrais jamais specifier de type concret en dehors de ta factory. >...
Tout a fait. J'ai mis en place tout un système de factory pour gérer les programmes réels :-) Mais a titre "éducatif" je trouve que la simplification a du bon :-) Je me permets de ton mél pour te demander ton avis sur le mél que j'ai posté hier sur EJB et JDO. Sachant que tu bosses quasi tout le temps avec des serveurs EJB, peux tu répondre à ces questions : -----EJB----- Pour EJB, deux questions se posent : 1 ) EJB permet-il de connaitre la modification d'une liste ? Par exemple : J'affiche sur un client Java la liste des cours ayant moins de 10 élèves. Pour cela j'utilise JList de Swing et un ListModel qui va bien. Par ailleurs 2 élèves s'inscrivent à un cours ayant déjà 9 élèves. Conséquence, ma liste doit être modifier (un cours vient de disparaître, 11 étant supérieur à 10). EJB a t'il une méthode standard ? En fait comment faire dépendre une liste d'un requête SQL modifiée par des changements externes (ici un cours obtient 11 élèves et donc devient sélectionné par le SELECT). 2 ) En considérant que l'application client/serveur existe comment puis-je la faire tourner en monoposte ? Je considère que tous les objets peuvent avoir une implémentation Locale. En fait je voudrais conservé du serveur EJB que la persistance. Par contre, je n'envisage pas d'installer et de configurer un serveur EJB complet sur chaque poste. Bref existe t'il une solution pour "compiler" un serveur d'EJB uniquement locaux ? -----JDO----- Une autre possibilité est de se contenter de JDO+RMI. JDO me permet d'avoir un seul développement pour monoposte et client serveur et RMI me permet le client/server. Dans ce cas quel est l'état de l'art en JDO. N'est-ce pas un peu tot ? JDO permet-il de connaitre la modification d'une liste ? Merci d'avance, -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél [EMAIL PROTECTED] -----Message d'origine----- De : Cedric Beust [mailto:[EMAIL PROTECTED]] Envoyé : lundi 9 décembre 2002 19:18 À : [EMAIL PROTECTED] Objet : Re: TR: Class static VS singleton Erik Mazoyer wrote: >Un grand avantage du singleton est l'héritage. > >Tu définis une classe singleton A. >Dans un premier temps tu écris A.gA = new A(); > >Plus tard, tu t'aperçois qu'il y a différentes implémentations possible >suivant les cas. > >Tu peux alors écrire >class B extends A... >class C extends A... > >Et au démarrage tu peut écrire > >A.gA = new A(); >ou >A.gA = new B(); >ou >A.gA = new C(); > C'est une bonne idee mais une mauvaise implementation :-) Tu ne devrais jamais specifier de type concret en dehors de ta factory. Pour plus de details : http://freeroller.net/page/cbeust/20021203 http://freeroller.net/page/cbeust/20021204 -- Cédric http://beust.com/weblog
