Discussion :

[ruda.tom]

Bonjour,

je suis tombé sur ce document il y a pas longtemps. La séparation des responsabilités du Backing Bean me semble intéressante (chapitre 9).
Cependant, je trouve l'exemple un peu simpliste. L'interface View possède une méthode getSelectedObjects. La page ne propose pas forcément d'élément sélectionnable, donc pour moi cette méthode n'a pas sa place dans l'interface. Le problème du coup c'est que l'interface est vide, et me semble donc inutile. Mais si il n'y a plus d'interface View, la méthode getView de l'interface Controller ne peut plus renvoyer un objet View .
Donc voilà, j'aimerais avoir votre avis sur :
- cette séparation des backing beans (il appelle ça MVC mais est ce vraiment le cas. Le MVC est déjà implémenté par le Faces servlet (C), les pages JSF (V) et le backing bean (M), non ? )
- le problème de l'interface vide

[djo.mos]

Bonjour.
Tout d'abord:

Bonjour,
Le MVC est déjà implémenté par le Faces servlet (C), les pages JSF (V) et le backing bean (M), non ? )

Non ! les backing beans font bel et bien partie du contrôle, et pas du model.


Ensuite, inutile d'essayer de pondre le backing bean générique et parfait qui s'adapte à touts les cas d'utilisations.
L'exemple donné dans le document en question est à prendre dans son contexte, qui est particulier. Alors de là à essayer de le généraliser à tout, ....

Exemple: le CRUD. Dans un cas pareil, il est possible (et même mieux) de créer une sorte de backing-bean générique.

Bonne chance.

[ruda.tom]

Merci pour ta réponse.

Mon but n'est pas d'avoir un backing bean générique mais simplement de séparer les différentes responsabilités des backing beans. Je trouve qu'avoir dans la même classe le binding des composants, les données et les actions n'est pas très lisible et un peu "fouilli".

Non ! les backing beans font bel et bien partie du contrôle, et pas du model.

Ce qui me frappe c'est que j'ai l'impression de lire tout et son contraire à ce sujet. Comme je l'ai dit dans mon premier post, j'ai lu que le backing bean faisait parti du model mais intuitivement j'ai plus l'impression que les actions font parties du Contrôleur et que les bindings des composants font partis de la Vue.
D'où ma volonté de séparation de mes backing beans.

[djo.mos]

Bonjour,
Je maintiens toujours que les Managed-beans font partie du Controller et non pas du Model. D'ailleurs, àde part son inception, JSF n'a rien à voir la couche Model.

Sinon, perso, je n'utilise que rarement le binding des composants (dans un seul cas au fait: pour pouvoir sélectionner le premier élément visible d'un data table). Je trouve ça un peu gore et non-élégant ... d'ailleurs j'aurais préféré que cette fonctionnalité soit dans le DataModel.

Sinon, je ne crois pas que le fait d'associer actions et données ne soit une mauvaise idée. C'est d'ailleurs le point fort de JSF. autrement, on aurait pu se contenter de Struts qui prône cette démarche (actions=Action, Données=ActionForm). Jettes un coup d'oeil sur cette discussion pour voir ce que l'on peut faire avec.

Je trouve qu'au contraire c'est plus flexible et plus productif d'associer les deux dans la couche contrôle ainsi que de pouvoir coder plusieurs actions dans un seul managed-bean.
Pour t'en convaincre, essaies de développer une même application de type CRUD avec Struts et avec JSF, tu verras la différence

[ruda.tom]

Je suis tout à fait d'accord avec toi sur le fait qu'il est très pratique d'avoir les actions et les données au même endroit. La solution définie dans le doc que j'ai cité ne fait que séparer pour une meilleure lisibilité. L'exemple fourni dans le post que tu cites est toujours possible avec cette solution. Le controleur serait alors défini ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public class PersonCtrl implements Controller {
  private Model model;
  //getter+setter
 
  public String addPerson(){
    ServiceOuDao.addPerson(this.getModel().getPerson());
  }
 
  public String autreAction(){
  }
}

le "model" (je reprends les termes du document mais c'est un peu perturbant par rapport à ce qu'on a dejà dit, je te l'accorde...) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public class PersonModel implements Model {
  private Person person=new Person();
  //getter+setter
 
}

et la JSP :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<h:inputText value="#{personCtrl.model.person.name}" />

[djo.mos]

Oki, je vois que ça peut être fait comme ça ... mais à quoi bon introduire un autre niveau d'indirection (ce que tu appèles Model) ?
Et pourquoi est ce que ce dernier implémente une interface ? du moment qu'il est une sorte de conteneur de données, et qu'une interface est censé représenter un aspect fonctionnel ...

Bref, si tu as peur que les classes de données (de type Person) dans ton contrôleur, tu peur le diviser en sous contrôleurs. Généralement, je m'y prends en un contrôleur par classe de donnée (Person PersonController, etc.).

Pour finir, essaies plutôt de te plonger dans le codage de quelques applications plus ou moins complexes (progressivement bien sûr), comme ça, tu pourras tester les diverses approches et te forger un avis basé sur l'expérience.

Bonne chance.