Reprise du message précédent :
Bon, question maitenant:
quels types de modele de developpement utilisez vous? Bien entendu, on ne peut pas comparer puisque tout depend de l'importance de l'equipe    
mais utilisez vous un modele 2 couches : IHM -> Serveur BDD
un modele 3 couches : IHM -> Logique métier -> BDD
un modele 5 couches : Client -> Couche présentation -> Couche métier -> Couche technique -> BDD
 
j'utilise le modele 3 couche, mais suis curieux de passer à un modele 5 couches, vos avis?  

moi, je fais surtout des applis ou des modules pour des applis web
 => couche présentation (jsp ou autre générateur de page)
 => couche métier (mon module ou mon appli)
 => couche technique (différents sous-modules techniques permettant d'abstraire les outils d'implémentation comme les outils de persistence des données, etc ...)
 => BDD (bha, c'est souvent ce qu'on utilise pour la persistence )
 
par contre, c'est quoi la couche "Client" ??

 
alors selon ce que j'ai lu, la couche client serait limitée à l'affichage et aux interactions utilisateurs.
Et la couche presentation (puisque pour moi c'etait ça!) serait la partie serveur rendant possible un acces à tout type de partie cliente via HTTP (pour le web) aux services métiers.

ok d'accord, donc pour moi la couche que tu appelles cliente c'est le processus d'IHM => le navigateur web.
 
bon, ben je fais du 5 couches alors

 
ben voilà, moi en 3 couches: client& presentation ne font qu'un (jsp ou servlets), de même pour la couche metier & couche technique (ou tout passe par des EJB)...
Va falloir que je me penche sur les 5 couches, plus pratique pour toute réutilisation

bha, c'est un peu de la connerie tout ca : la couche métier est toujours elle même décomposées en couche (dans des projets un tant soit peu sérieux) => c'est un peu du pipo tout ca ...

oui, et par exemple le l'obligation d'avoir un constructeur sans argument est un truc technique (ça n'a en général pas de sens dans le modèle, mais c'est utile pour la persistance par exemple). Mais qu'on le veuille ou non au niveau métier on est obligé de l'avoir (donc pour ceux qui ne sont pas des porcs, de rajouter un état possible pour l'objet et tout le bordel dans les contrats).

   
tu causes de javabean là ?  
ckoi le raport ?

petit drapeau

aucun, d'ailleur j'aurais du poster ça dans la catégorie Ada.

 
 
edit : me dis pas que tu confonds javabean et EJB

non, mais j'ai pas fait gaffe un truc.
 
Il est obligatoire en persistance gérée par le conteneur (CMP), formulation qui suppose que sinon il est pas obligatoire.
 
ça change effectivement, si le CMP est bien la grosse bouse qu'on m'a décrite et que donc il est inutilisable en prod, alors on s'en fout et les objets ont la possibilité d'être plus simple (ou du moins, si on s'occupe de la persistance à la main, il est normal de devoir s'occuper avec des états de l'objet associés).
Par contre, si le CMP devient un truc crédible (ce qu'on peut espérer, bordel si on sait faire des trucs compliqués propres, on doit bien arriver à faire du SQL correctement), alors il faudra virer cette contrainte.
 
C'est d'ailleur pour ça que je gueule contre les formes de Coplien en C++ : c'est ("ça devrait" dans ces 2 cas) être le modèle qui dicte le contenu d'une classe, et les états possibles des objets, pas des contraintes "tecniques". Pas la peine de m'expliquer, pourquoi Coplien a proposé son truc : on est dans un topic java, et je le sais très bien.

en quoi c'est gênant ? on ne se servira jamais directement du constructeur du bean ... c'est le conteneur qui nécessite un constructeur vide. La création de l'EJB se fera ensuite par la home interface.
 
Je saisie pas bien en quoi c'est génant puisque dans le cas des EJB, c'est la home et la remote qui servent de signature ... l'objet bean n'est qu'une brique technique, il ne fait pas vraiment partit du modèle ...

ok

 
plus tu utilises couche plus tu peux adapter a différente technologie... mais plus tu perds en performances

pas toujours ...

ste plé benou ....  
lance pas de débat comme ça quoi, c peine perdue

ah bon ? explique stp ?

désolé ...

je voulais juste dire que parfois, le découpage en couche n'est pas une surcharge mais juste une architecture mieux pensée, et pas forcément moins performante ...
 
découpé en couche, c'est juste "fortement" modulariser ... la modularité n'est pas forcément signe de baisse de perf.
 
voilà, ca allait pas plus loins que ca ... je voulais juste ne pas laisser passer la remarque d'os2 sans réaction

c'est certain que c'est mieux penser
pas forcément, mais très fortement
où serait plus performant d'avoir plusieurs couche?
 
on n'a qu'à pensé au temps réel un 3ms seconde peut faire toute la différence....
 
c'est très normal que
1 - IHM -> Serveur BDD
2 - un modele 3 couches : IHM -> Logique métier -> BDD
 
1 aille plus vide que 2
 
si comme dire qu'utiliser une dll tierce pour nous facilité la vie pour l'accès à une bd serait plus rapide qu'utiliser directement les api de la bd
 
quelque architecture intéressante et pratique: centré sur les donnée, flux de donnée, appel et retour, en couche
 
pour ceux que ça intéresse de savoir quel architecture utilisé... la méthode adam existe

 
 
Les serveurs d'application (puisqu'au travers de J2EE, c'est bien de serveurs d'application dont on parle), ce n'est pas seulement l'architecture n-Tiers que l'on traite, mais aussi l'approche par composants, une architecture transactionnelle..
 
Au fait, pour rappel, l'architecture n-Tiers permet le "Clustering" et le "load balancing" .. alors niveau perfs, ça peut être assez intéressant si il y a beaucoup d'accès simultanés par exemple..
Qqun peut il confirmer concrètement ? qui  a participé à un projet J2EE avec clustering ?