# Conseil - Comment modéliser MVC ?



## Vampyre (26 Mai 2011)

Bonjour, 

Débutant sous XCode (comprenez que cela fait des mois que j'étudie l'Objective-C d'abord, puis suis passé à XCode 4. N'ayant pas de livre pour XCode 4, j'ai fait l'effort de trouver moi-même comment adapter le code exemple pour qu'il fonctionne sans bug dans XCode 4). Bref, pas mal étudié et bouquiné...

Cependant, un des détails qui me bloque encore, est la conceptualisation en suivant le modèle MVC.

C'est pourquoi, je me permets de chercher quelques conseils : comment conceptualisez vous vos applis en appliquant le modèle MVC ? Feuille de papier et en avant ? Vous écrivez quoi au juste ? Un beau dessin pour le V ? Une logique pour le C ? et une liste pour le M ? Enfin bref, comment puis-je attaquer un sujet et le décortiquer en modèle MVC afin de ne pas me perdre lors de la programmation ?

Grand merci à vous pour vos conseils


----------



## Rez2a (26 Mai 2011)

Bon alors je ne suis pas un expert en théorie, donc je vais sûrement me faire reprendre de volée par les puristes genre tatouille & cie mais tant pis. 

Voilà comment je procède de manière perso si ça peut t'aider, mais ça n'engage que moi :

- je commence par lister les fonctionnalités voulues de l'appli en rentrant assez dans le détail, sur papier ou document texte, peu importe.
- une fois terminé, je refais le tour de ce que j'ai listé, et si je vois que c'est allé trop loin sur certains trucs, je les supprime ;  pas pour ne pas me casser la tête, mais parce que trop de fonctionnalités tendent à complexifier l'appli et son interface, et je préfère éviter.
- quand c'est fait, j'ai déjà une petite idée de l'interface générale en tête : soit c'est très simple et je me passe de maquettes, soit je fais des petits dessins sur papier avec l'interface schématisée et les liens entre les différents écrans, soit ça se passe dans les règles de l'art et c'est écran par écran en faisant des maquettes sous Photoshop (des éléments d'interface sont facilement trouvables en PSD) : ça permet de se rendre compte tout de suite si un truc ne va pas (écrans mal enchaînés, répétition d'infos, etc.).

Au niveau du code ensuite, je pense qu'il ne faut pas tant se casser la tête que ça pour respecter le pattern MVC car Cocoa EST MVC.

- les views, ça passe évidemment par les .xibs, avec les outlets linkés aux controllers correspondants.
- les controllers, la classe UIViewController est là pour ça ; un truc très simple pour se rendre compte si on respecte bien MVC, c'est de garder à l'esprit que depuis les applis universelles, on peut utiliser un UIViewController pour deux xibs : un pour iPhone, un pour iPad. Si on se rend compte qu'on peut avoir deux interfaces différentes s'appuyant sur le même controller, je pense qu'on peut dire que c'est bon.
- le modèle, souvent c'est là que je triche un peu : pour le modèle de données en lui-même, encore une fois Core Data est là pour aider et on peut difficilement se tromper. Pour les traitements des données, j'ai souvent tendance à les inclure dans les classes des ViewControllers lorsque ce sont des traitements simples (mauvaise façon je pense), ou je passe par un NSObject à part (ce qui permet d'effectuer les mêmes traitements depuis plusieurs ViewControllers).

Après, encore une fois, je ne garantis pas que ce soit la bonne procédure.
Cela dit, à mon avis, le plus important sur une appli c'est surtout le travail à faire sur le listage des fonctionnalités et la clarté et simplicité de l'interface ; si tu as ça, lorsque tu attaqueras l'appli au niveau du code, tu te rendras vite compte si tu pars dans la bonne direction ou pas, en fonction du nombre de galères que tu te frapperas. 

Quelques petites remarques, qui encore une fois n'engagent que moi :
- l'habitude ça ne s'invente pas, plus tu coderas et plus tu gagneras en vision d'ensemble, tu sauras direct les erreurs à ne pas faire et les contraintes liées à ce que tu souhaites coder, et plus vite tu utiliseras les composants standards (une UITableView par exemple, au début c'est un peu déroutant, mais avec l'habitude ça se code très vite).
- l'optimisation, les tests et le travail sur la stabilité, c'est très important ; perso, je remarque une baisse générale de la qualité des applis, il suffit de regarder Facebook qui me claque dans les mains au moins 5 fois par jour depuis les dernières mises à jour pour se rendre compte que c'est juste insupportable ; alors surtout, travailler sur l'optimisation, la tolérance aux pertes de réseau, la mémoire, les bugs... une appli stable c'est quand même bien agréable.
- enfin c'est très personnel, mais je préfère une appli au design épuré qui tourne très rapidement et qui fait ce que je lui demande, plutôt qu'une appli au design tellement travaillé qu'il faut l'utiliser plusieurs fois pour en saisir toutes les possibilités, voire qui en devient lourde. Bien sûr ça dépend du calibre de l'appli, mais généralement la plupart des lourdeurs qu'on voit sont évitable si il y avait eu un peu plus de travail en amont.

Enfin bonne chance, car le plus dur est devant toi, ça prend quand même pas mal de temps pour faire le tour de Cocoa et pour savoir quel composant utiliser à tel endroit, et surtout pour savoir les utiliser de la bonne façon ; tu peux avoir un schéma MVC aux petits oignons, si au final l'appli est codée salement, elle ne sera jamais top. 

[Edit]
Désolé, les termes que j'emploie font surtout référence à Cocoa Touch pour iOS, mais rien dans ton post n'indique que tu te portes plus sur iOS que sur OS X... cela dit, j'imagine que la logique d'ensemble reste la même entre les deux.


----------



## Vampyre (26 Mai 2011)

Un très grand merci pour cette longue réponse qui, effectivement, m'aide à y voir plus clair... Au niveau de mon apprentissage, j'ai essayé d'éviter les bouquins trop pointus qui ne montrent que du iPhone, ou que du iPad, ou que du Mac OS X. Tant qu'à apprendre, autant apprendre tout ce qui est commun aux trois, et puis une fois habitué, aller plus en profondeur sur l'un ou sur l'autre.

Dans un premier temps, l'appli que j'ai en tête devrait tourner sous Mac OS X. C'est une appli qui me manque vraiment, et ce que j'ai trouvé comme soft existant est soit très pauvre, soit très vieux (pré-2005 parfois) et plus maintenu. Comme c'est une appli qui est relativement ouverte, elle va me permettre d'apprendre plus en profondeur.

Egalement, au niveau de mon passé en programmation, je ne suis pas tant débutant que cela... J'ai commencé sur Commodore 64 à l'âge de 9 ou 10 ans, enchaîné avec Basic, QBasic, Pascal, Turbo Pascal, Delphi puis Visual Basic. Et puis j'ai lâché pendant un sérieux paquet d'années... Je suis donc capable d'évaluer et de trouver une logique. Le plus déroutant pour moi, c'est l'orientation objet, mais je m'y fais très bien à cette logique, certe déconcertante au début, mais c'est juste un pli à prendre...

Et enfin, ne t'inquiète pas, je ne me prends pas pour le super développeur qui va sortir l'Appli qui va tout casser sur sa route et faire des millions sur l'app store. Tout au plus, lorsque j'aurai terminé cette appli, je la vois comme très utile d'un point de vue personnel. Peut-être la mettrai-je sur l'app store, mais rien n'est très sûr... J'ai donc tout mon temps d'apprendre, et je le fais sérieusement... Pas de soucis là dessus... 

Merci pour tes conseils, cela m'aide vraiment... A bientôt !


----------



## Céroce (27 Mai 2011)

Rez2a a dit:


> - le modèle, souvent c'est là que je triche un peu : pour le modèle de données en lui-même, encore une fois Core Data est là pour aider et on peut difficilement se tromper. Pour les traitements des données, j'ai souvent tendance à les inclure dans les classes des ViewControllers lorsque ce sont des traitements simples (mauvaise façon je pense), ou je passe par un NSObject à part (ce qui permet d'effectuer les mêmes traitements depuis plusieurs ViewControllers).



Voilà mon seul point de désaccord: il faut faire tous les traitements dans la partie Modèle et non dans la partie Contrôleur, parce que:
- la philosophie du MVC est de séparer les composants "métier" de leur représentation. Les traitements font partie de la logique métier, et doivent se trouver dans le modèle.
- cela permet d'utiliser les traitements à plusieurs endroits sans duplication
- cela cache les détails d'implémentation du modèle au contrôleur. Le but de la POO est de limiter les dépendances entre composants logiciels.

Avec Core Data, les entités peuvent être instanciées sous forme de NSManagedObjects auxquels on rajoutera les méthodes de traitement, plutôt que créer des NSObjets à part qu'on ne saura pas trop comment nommer et auxquels il faudra passer les données.

Pour le reste, la démarche me paraît bonne. Il est surtout important d'avoir une partie métier bien carrée avant de se lancer dans le codage de l'IHM (les tests unitaires sont bien utile pour la mettre au point); autrement, il va falloir reprendre la partie métier, puis à nouveau l'IHM; c'est une grosse perte de temps et de motivation.
Enfin, créer une appli est un processus itératif, je ne dis pas qu'il faut faire toute la partie métier avant d'attaquer l'IHM, mais plutôt travailler fonctionnalité par fonctionnalité.


----------

