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.

[ruda.tom]

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 ...

il s'agit juste là d'avoir une meilleure lisibilté et un formalisme. Ainsi, dans la JSP, toutes les données seront de la forme suivante :

Code :

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

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

et tous les bindings de composants :

Code :

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

<h:inputText binding="#{personCtrl.view.xxxx}" />

Donc les interfaces seraient utiles pour le formalisme, mais je suis d'accord que ça n'a pas d'aspect fonctionnel (on le voit bien puisque l'interface est vide). Mais je ne vois pas comment faire sans interface. Si quelqu'un a une idée...

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.).

et tes actions tu les mets dans tes classes héritées ou toues les le controlleur de base ?

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.

J'ai déjà développé 2-3 applis en JSF sans cette approche. Je comptais essayer ça dans ma prochaine application, mais je voulais avoir une solution à ce problème d'interface vide.

[djo.mos]

Concernant le problème d'interface vide ... Qu'est ce qui t'oblige à passer par une interface ? Je comprends pas du tout ...

[ruda.tom]

Concernant le problème d'interface vide ... Qu'est ce qui t'oblige à passer par une interface ?

Si on reprend le diagramme de la solution proposée dans le document que j'ai cité, le seul moyen de ne pas avoir d'interface (Model et View) serait de ne pas avoir également d'interface pour le controleur (Controller). On aurait alors de simples POJO. Et pour que je puisse utiliser le formalisme dont je parle, il faut absolument que tous mes controleurs définissent une méthode getView et getModel.
J'espère que c'est un peu plus clair...

[djo.mos]

Nop, désolé, pas compris; c'est un peu trop tordu à mon gout ...Là, j'ai pas accès au PDF en question.
Anyway, pour un contrôleur CRUD, voici comment je m'y prend:
DAO:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
public interface IGenericDao<T> {
	/**
         * Ajoute une entité à la BD
         * @param entity l'entité à ajouter
         */
	public void insert(T entity);
 
	/**
         * Supprime une entité de la BD
         * @param entity l'entité à supprimer
         */
	public void delete(T entity);
 
	/**
         * Met à jour une entité dans la BD
         * @param entity l'entité à mettre à jour
         */
	public void update(T entity);
 
	/**
         * récupère la liste de toutes les entités de la BD
         * @return liste d'entités
         */
	public List<T> select();
}

Interface d'un controlleur CRUD:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
public interface ICrudController<T> {
	/**
         * Utilisé lors de l'affichage via une dataTable
         * @return liste de toutes les entités
         */
	public List<T> getList();
 
	/**
         * effectue la  création d'une entité
         * @return le outcome pour redériger à une page particulière
         */
	public String create();
 
	/**
         * effectue la  suppression d'une entité
         * @return le outcome pour redériger à une page particulière
         */
	public String delete();
 
	/**
         * effectue la  mise à jour d'une entité
         * @return le outcome pour redériger à une page particulière
         */
	public String update();
 
	/**
         * Permet de sélectionner l'entité sur laquelle on travaille.
         * @return
         */
	public String select();
}

Une implémentation générique:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
@Controller
@Scope("session")
public class GenericCrudController<T> implements ICrudController<T> {
	protected List<T> entities;
	protected DataModel model;
	protected T entity;
 
	@Resource
	protected IGenericDao<T> dao;
 
	@Override
	public String create() {
		dao.insert(entity);
		entities = dao.select();
		return null;
	}
 
	@Override
	public String delete() {
		dao.delete(entity);
		entities = dao.select();
		return null;
	}
 
	@Override
	public List<T> getList() {
		return entities;
	}
 
	@Override
	public String select() {
		entity = (T) model.getRowData();
		return null;
	}
 
	@Override
	public String update() {
		dao.update(entity);
		entities = dao.select();
		return null;
	}
}

Une implémentation dans le cas particulier d'une entité PErson:

Code :

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

1
2
3
4
 
public class PersonController extends GenericCrudController<Person> {
 
}

Et voilou ! Bon, il manque pas mal de trucs (les getters+setters, l'initiantiation d'un type générique (entity), etc.) mais cette squeulette est quasi-fonctionnele.
N.B.: Ne te préoccupe pas des annotations @Controlller, @REsource, @Scope, etc. ce sont des trucs de Spring, et ne sont pas obligatoires.

[ruda.tom]

Je mets le diagramme de classes du document dont je parle pour plus de clarté (enfin je crois...)