novembre
2009
Suite à son dernier article, je suis tombé sur le blog de julien et en remontant le temps, j’ai eu envie de réagir à son premier billet.
Comme mes commentaires commençaient à s’allonger, j’ai préféré rédigé ce petit billet.
- Quand je faisais du Swing et du JDBC, j’aimai bien à partir de mes ResultSet remplir un objet métier qui implémentait une interface modèle de la vue (GridModel, ListLodel, …) qui pouvait être présenté différemment par un Renderer. Cela évitait ainsi des recopies inutiles.
- En GXT, j’ai essayé de faire la même chose en remplissant avec Ibatis des Maps qui implémentent ModelData (l’interface des modèles de données dans GXT).
Dans les deux cas, il y a une « adhérence » aux interfaces « Model » d’une couche graphique (Swing, GXT).
Et si cela me dérangeait moins en Swing à l’époque, avec le web, ça me plaît pas trop.
Du coup, je me demande si deux objets ne sont pas nécessaires puisqu’ils ont deux responsabilités différentes :
- Un type d’objet MA qui sert de conteneur de données (POJO du modèle de l’application)
- Un type d’objet MV qui sert d’objet de rendu (Modèle de donnée d’un composant de la vue de l’application) qui représente directement des MA ou une vue consolidée de MA)
Et donc une recopie partielle des données d’un MA dans un MV ?
Ce qui illustre de plus en plus ce sentiment que j’ai que le MVC s’applique à plusieurs niveaux :
- Un MVC global au niveau de l’application métier : Des vues (Vue) qui permettent via des actions (Contrôleur) de traiter des données (Modèle)
- Un MVC local au niveau d’objets techniques : les composants graphiques d’une couche de présentation, ceux qui servent à construire les vues de l’application métier.
Et vous, qu’en pensez vous ?