Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
fonctionnement de l'MVC egard JSF
salut tout le monde ,
je suis entrain de developper une application web plateforme j2ee sur le seveur d'application websphere d'IBM,j'ai adopte l'architecture MVC pour separer la partie logique de la partie presentation..mais je travaille sur framework JSF et je ne sais pas cmt il fonctionne MVC egard ce framework.est ce que vous pouvez m'aidez de citer les principes fonctionnement de l'MVC?
merci
salut Essof () ca va ton projet ca avance.
bon MVC c'est Model View Controller
Model pour Metier
View pour Interface Utilisateur
Controller pour Controlleur.
ca c'est pour le MVC.
maintenant comment JSF implemente ces couches?
il a les beans(managed-bean) pour modeliser la couche metier.
la FacesServlet comme controlleur.
et les pages JSF pour les Interfaces Utilisateurs.
Bravo pour les confusions !
pour une application simple on peut discerner 3 couches:
- Présentation = qui se charge d'interfacer l'application avec le reste de l'univers.
- Metier = qui se charge de réaliser ce pour quoi est faite l'application
- Données = qui a la responsabilité des données nécessaires à la réalisation de la couche métier. (ca peut etre avec ou sans état), et ca peut etre relié à la couche:
- Persistance
La couche présentation peut etre:
- une interface ligne de commande genre ms dos, surtout pour la communication avec d'autres programmes
- une interface purement réseau pour la communication avec des machines
- une IHM=GUI pour la communication avec des humains
Une IHM c'est quelque chose de bien compliqué, c'est déjà une application en soit.
Dans une IHM on trouve:
- une sous couche présentation=graphisme et inputs dédié à un écran on parle alors de Vue
- un model=ensemble d'infos qui composent l'IHM, on fait référence en parlant à l'info qui peut changer. Dans ces info on trouve des infos:
1 purement IHM=état d'un bouton, selection etc...
2 relative à la couche donnée: nom d'une personne etc...
- le controleur a surtout pour fonction de gérer les changements d'états de l'IHM
1 Interaction graphique (je selectionne ceci, alors ici ca doit etre sélectionné aussi...)
2 La navigation sur différentes vue et pour se faire:
3 Les interactions avec couche métier de l'application.
Quand on rentre plus dans l'architecture de l'IHM on tombe sur les composants qui eux suivent maintenant le pattern UI delegate, ou le model et le controlleur sont couplés tandis que la représentation graphique est déléguée à un renderer spécialisé; c'est que la pour JSF et Swing.
Pour JSF par de soucis, le MVC est bien découplé, au niveau IHM.
Par contre méfiez vous lors du développement de bien découplé le framework JSF qui est un framework présentation des couches données et métier.
JSF fait un binding vers des managed bean qui peuvent etre du model purement graphique aussi bien que des données applicatives.
Demandais vous toujours si votre logiciel peut fonctionner sans l'IHM.
Je pourrai en parler pendant des heures.
So please, ne parlez plus de MVC en faisant référence à une application, d'aujourd'hui.
peut explique Alec6 pourquoi on peut pas parler du MVC avec JSF ??
Si si, c'est bien du mvc qu'on peut faire avec JSF dans la couche présentation.
C'était juste pour rectifier tes explications; comme tu le dis
- model est à implémenté en JAVA et se lie à la vue par l'intermédiaire des EL dans les attributs "value" (value="#{monBean.monAttribut}")
- le ou les controleurs sont appelés par la vue avec les attributs actionListener etc à l'aide des EL
- la vue c'est du xml de JSF
la technique des managed bean simplifie la liaison avec les objets models, donc de la sous couche model de la couche présentation, mais aussi avec les objets de controles (il y a une disctinction entre managed beans et backing beans, mais je reste encore confu sur ce point);
Il faut distinguer les objets models de la sous couche présentation qui contiennent des informations sur la vue (genre un boutons et grisés) de ceux qui représentent une information dans la couche donnée. Souvent on encapsule objet de données de la couche données dans des décorateurs ou adaptateurs au niveau présentation, pour qu'il soit utilisable par la vue.
Donc JSF fait bien du mvc, mais ne vous trompez pas sur ce q'est le mvc (trois sous couches dans la couche présentation).
je t'explique alec6 mes propos quand on parle du MVC on parle bien du design pattern MVC sous entendu de design pattern on parle de framework de conception .
pour utiliser le design pattern MVC(ici on parlera du MVC2) il faux (de point de vue conceptuelle de notre application) separe le model metier de la partie specifique a la gestion de view(UI).
donc nos managed bean effectue la partie lier aux metier quand tu dis que
ce la entend dire qu'ilya une separation entre les managed bean et les bean metier tandis que q'on peux utiliser les bean metier comme managed bean.la technique des managed bean simplifie la liaison avec les objets models,
et nos page JSF
le view et le controlleur c'est FacesServlet.
le mapping view-metier ce fait par les ELs.
Cependant, c'est vrai que point de vue developpement on peut delegue une partie de la gestion des view a des managed bean .
2 Remarques :Envoyé par seddik_saber
- A propos d'utiliser les beans métier comme managed bean : pas vraiment joli comme technique ! c'est plus court, c'est vrai, mais pas joli du tout ! A moins bien sur d'utiliser le pattern DTO/DAO et d'utiliser les propriétés des DTO pour le binding des composants et les méthodes des DAO dans les actions.
- le View, le Controller, etc. : Perso, je pense que ces allégations sont trop simplistes et ne reflètent pas la réalité ! La réalité est un peu plus complexe que ça ! le Controller ne saurait être resumé à FacesServlet ! Cette dernière est le back-end, la vrai logique du controle émane plutot des actions des managed beans (les public String xxxx(){}).
Je pense que ce post risque fort de tourner en une guerre sans merci où chacun défend sa vision des choses, mais avant d'en arriver là, il faut se rappeler de cette règle d'or : Si on se trouve en train de modifier les classes du model pour pouvoir les utiliser dans la partie View/Controller, alors àa craint fort ! on est en train de casser le pattern MVC !
Par exemple, ce n'est pas parceque JSF ne sait pas travailler directement avec les enums que l'on doit les changer en String dans le model ! Il vaut mieux faire plus d'effort et ajouter un champ String dans un managed bean, lier ce champ au composant, et le convertir vers un enum à l'appel d'une action !
J'espère que j'ai pu expliquer la chose !
Pas de soucis ca va pas tourner à la guerre le MVC;
je suis d'accord avec toi Modjo, et au final ton managed bean devient un adaptateur de ton enum pour que JSF puisse l'utiliser.
Perso j'aime beaucoup la modélisation et je trouve qu'en architecture (définition des couches, composants, modules etc)... ca manque de formalisme en informatique, au niveau des définitions, et de la façon de s'y prendre, etc... et des débats nous aiderai a faire avancer notre vision, et donc à produire des logiciels plus facilent à faire évoluer.
Remarque c'est en ca qu'on distingue les séniors.
Je vous conseils de lire l'intro de serge tahé sur spring; c'est très bien ca fixe bien les idées.
Pour seddik_saber, ce que je veux dire (je pense que c'est pareil pour Modjo, ou j'ai pas compris), c'est que le M de MVC vaut mieux eviter que ca soit directement des beans metiers. Il vaut mieux faire tes propres objets, qui vont encapsuler des beans metiers. Et ca arrive souvent en faite par exemple quand tu as une structure de données que tu veux représenter sous la forme d'une arborescence ou d'un graphe. Tu te retrouves a creer des objets qui encapsule les données et qui sont chargées de faire les relations dans l'arborescence ou le graphe.
Avec cette encapsulation, c'est un wrapper qui et à la fois décorateur et adaptateur, si demain on te change le model de données, ou que tu veux appliquer ton IHM à une autre couche métier, tu as juste à modifier ou développer un autre wrapper. Ainsi tu as:
V - C - Model GUI 1 - Model métier
Voilà, en somme on va tous s'en payer une couche, ou plusieurs
Du moment que ça traite du GUI, on n'est plus dans le model je pense ! Remarques que je suis d'accord avec toi sur le principe du wrapper entre le Model et les Views, je conteste juste le fait que tu l'assimile au model. Perso, je dirais que ça appartient plutôt au Controller, qui à part le fait de controller le navigation flow, fait aussi office de colle et d'adaptateur entre le Model et les Views !
C'est bien un model mais dans la couche presentation; (comme je le disais plus haut comme les applications sont très complexes de nos jours, avec un logique de présentation, une logique métier, une logique de persistance etc..., le model dans le MVC ne s'apparente plus au Model de la couche model de l'application proprement dite).
On a cette arborescence:
Couche presentation:
- Vue (variable, du téléphone à l'ordi stand alone)
- Controlleur de la vue (controle la navigation et par exemple si un bouton doit etre grisé etc...)
- Model de la vue qui comprend des infos purement graphique: couleur d'une ligne d'un tableau et aussi des info provenant de la couche données de l'application
Couche données:
- Contient le model de données sur lequel travaille la couche métier
Cette couche dispose souvent d'une logique d'auto chargement pour du lazy loading, en effet c'est un repository de données
Couche métier:
- Contient les commandes métiers, appelées par la couche présentation (en générale par le controleur de la couche présentation qui sert de facade)
- Modifie le modèle de la couche données
Couche persistance
Bien sur tout ca et pas toujours facile à découpler... mais c'est une autre histoire
Répondre avec citation
Partager