Discussion :

[keviin55]

Bonsoir tout le monde ,
j'ai lus des tonnes de truc sur le MVC et je croyais avoir compris le principe.Mais là je suis dans un cas que je ne comprend pas.Pourriez vous s'il vous plait m'aider à identifier mon model .
Mon projet consiste à un service web RESTful et une application iphone .Logiquement , ma vue c'est l'interface sur iphone ,les contrôleurs c'est les classes reliés à la vue et mon model , c'est le service web . Es que c'est correcte de mettre le service web comme model ?
En plus , dans mon application iphone , j'ai des contrôleurs , mais j'ai aussi des classes que je n'arrive pas à trouver dans quel groupe mettre . Par exemple , la classe RecetteController contacte le service web , télécharge le json , le parse et crée un Tablaux avec des Objet d'une classe Recette , qui ne contient que des attributs , aucune méthode . Es que la classe Recette fait partie du groupe Model ?
Aider moi svp , merci beaucoup d'avance

[Nico02]

Je suis pas un grand spécialiste du web service mais ce que je peux te dire c'est que la partie modèle dois regrouper toutes les données et les classes métiers de ton application. Donc la réponse dépend de comment tu souhaites gérer ces données.

Si tu récupères certaines données via ton web service et que tu fais des traitements dans ton application iphone, alors je pense qu'il faut considérer ton modèle MVC uniquement sur ton appli iphone, la partie modèle deviens alors l'ensemble des classes effectuant ces traitements dans cette appli. Le web service lui utiliserait un point d'entré dans ton contrôleur pour venir mettre à jour tes données dons le modèle. Il représenterait alors une sorte un modèle annexe.

Code :

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

1
2
3
4
5
6
7
8
                        Web Service
                                 |
     ---------------------------------------------------------  
   appli iphone  :            contrôleur 
                              /     \
                            /        \
                           modèle<==>Vue

[kayoum]

Je suis pas tout à fait d'accord avec ca. Le modèle n'est pas le service web dans ton propre exemple.

Dans ton cas, le modèle contient des information qu'il tire du service web via des méthodes getXXX() pour mettre à jour ses données et informer la vue des changements.

Le modèle est donc un objet qui contient toutes les informations présentes dans la vue et des méthodes de synhcronisation avec le webservice.

Attention à une chose aussi, il ne fait pas croire qu'une classe = soit un modèle soit une vue, soit un controlleur. Tu peux très bien mettre les classes de contrôles dans les mêmes classes que les vues dont ils dépendent. Le modèle VMC c'est une façon d'organiser les choses. Dans ton exemple, oui c'est correct de considérer que la Recette fait parti du modèle.

L'exemple de Nico2 est également valable, dans ce cas c'est au contrôlleur d'interroger le webservice.

Mais alors dans ce cas peut être est il préférable de considérer le webservice en tant que modèle et ne pas répliquer les informations (supprimer la classe Recette du coup) à toi de voir les choses. Le modèle MVC peut être utilisé de plusieurs façon.

[Nico02]

Attention à une chose aussi, il ne fait pas croire qu'une classe = soit un modèle soit une vue, soit un contrôleur.

Complètement d'accord, dans le modèle MVC le contrôleur représente le moyen de synchroniser les actions des utilisateurs sur la vue (ton IHM) avec les données du modèle, cela n'exclue en rien le fait de pouvoir avoir des classes de contrôles entres tes classes métiers.

Mais alors dans ce cas peut être est il préférable de considérer le webservice en tant que modèle et ne pas répliquer les informations (supprimer la classe Recette du coup) à toi de voir les choses.

Je pense que cela dépend vraiment de l'utilisation que l'on veut faire avec ces données. Si il faut simplement allé chercher des données au travers du web services pour ensuite les affiché je suis d'accord, par contre si il y à des traitements à effectuer sur ces données, il peut être préférable dans garder une partie dans l'application pour éviter un utilisation massive du web service. Encore une fois cela dépend vraiment de l'utilisation.

[kayoum]

Je pense que cela dépend vraiment de l'utilisation que l'on veut faire avec ces données. Si il faut simplement allé chercher des données au travers du web services pour ensuite les affiché je suis d'accord, par contre si il y à des traitements à effectuer sur ces données, il peut être préférable dans garder une partie dans l'application pour éviter un utilisation massive du web service. Encore une fois cela dépend vraiment de l'utilisation.

Tout à fait d'accord puisque le rôle du modèle est justement la gestion des données !!

[hegros]

D'un point de vue strictement Grasp Pattern un contrôleur c'est la solution au problème "A qui envoyer un message provenant d'une IHM ? Au contrôleur"


Après de manière générale un WS c'est un contrôleur (il ne gère pas que les données il y a aussi le transport, la sécurité, les sessions etc...) puisqu'il va faire l'interface entre l'utilisateur (via une IHM) et des données (le modèle) et cela peut importe que l'architecture soit N-Tiers ou pas (par exemple une IHM sur un IPhone, un WebService hébergé en Inde et une base de données hébergée en Australie)


Pour répondre à ta dernière question. Oui "recette" c'est probablement une classe du modèle et "RecetteContrôler" comme son nom et son rôle semble l'indiquer c'est un contrôler.

On pourrais voir la séquence ainsi :

Depuis l'ihm Iphone : LabelTemperature = ControleurMeteo.AppelerWebServiceMeteo();

Depuis le ControleurMeteo : return ControleurWebService.RecupereMeteo();

Depuis le WebService : return ModelMeteo.RecupereTemperatureCourante()

Il y a clairement un niveau d'indirection et le Web Service n'est pas le modèle puisqu'il l'utilise.