Nous avons fait tous les préparatifs de notre application. Et maintenant que vous vous êtes un peu échauffés, nous allons pouvoir attaquer le chapitre le plus important de ce cours : la découverte du MVC ! Est-ce que vous êtes prêts ?
Vous n’avez pas l'air tout à fait prêt... Est-ce que vous êtes vraiment prêts ?
Je préfère ! Alors, allons-y !
Un patron de conception
Le MVC est ce que l'on appelle un patron de conception. Parfois il est inutile de réinventer la roue, alors je vous propose la définition Wikipédia du patron de conception, la meilleure que j'ai pu trouver.
En informatique, et plus particulièrement en développement logiciel, un patron de conception (souvent appelé design pattern) est un arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d'un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels.
Un patron de conception, c'est donc une organisation des modules qui vont composer notre programme.
Ça sert à quoi ?
Et bien ça sert simplement à s'organiser. C'est aussi bête que ça. Vous vous rendrez vite compte que dès que votre projet dépasse quelques centaines de lignes de code, ce qui arrive très vite, vous serez vite perdus si vous ne vous organisez pas. Vous ne saurez plus où se trouve telle ou telle fonction, à quoi sert tel fichier, etc. Et c'est comme ça qu'arrivent les bugs car tout se mélange dans votre code !
C'est donc très important d'organiser son code clairement !
C'est hyper important d'organiser son code clairement !
C'est ultra important d'organiser son code clairement !
Quand on choisit un patron de conception pour une application, on s'engage à en respecter les règles.
MVC, le choix d'Apple
Apple a choisi par défaut le très populaire patron de conception MVC pour les applications iPhone. Cela veut dire que la façon dont ils ont conçu le développement d'application iPhone nous encourage à respecter le design MVC.
La bonne nouvelle, c'est que parmi les dizaines de design pattern existant, le MVC est assez simple et pour autant assez puissant.
MVC, pour Modèle Vue Contrôleur
Bon alors qu'est-ce que le MVC ? Le MVC est d'abord un sigle qui signifie Modèle Vue Contrôleur. Avec le MVC, nous allons donc séparer notre programme en trois parties comme ceci :
Alors qui fait quoi ?
Le modèle : c'est ce que fait l'application. C'est la logique, le cerveau de l'application.
Le contrôleur : il récupère les informations du modèle et les affiche dans la vue.
La vue : c'est ce que l'utilisateur voit, c'est l'interface de l'application.
OK et concrètement ?
Bon, prenons l'exemple de l'application calculatrice. Le programme de cette application est divisé en trois selon le modèle MVC. Voyons ce qu'il se passe lorsqu'un calcul a lieu.
La vue détecte que le bouton égal a été appuyé. Elle fait passer l'information au contrôleur.
Le contrôleur interroge le modèle en lui passant les informations nécessaires : les nombres de l'opération et le type d'opération demandée.
Le modèle reçoit les nombres et les opérations et fait les calculs correspondants. Il passe le résultat au contrôleur.
Le contrôleur reçoit le résultat et l'envoie à la vue.
La vue affiche le résultat à l'écran.
On peut résumer le modèle MVC avec la phrase suivante :
Le contrôleur interprète et formate les informations du modèle pour les passer à la vue.
Les règles de communication du MVC
Le MVC, c'est avant tout une règle de communication. Cette règle définit la façon dont les différentes parties doivent communiquer. Tout le monde ne peut pas communiquer avec tout le monde sinon ça ne sert à rien de faire des parties différentes :D !
Et la règle d’or, la voici :
La vue et le modèle ne peuvent JAMAIS communiquer.
Cela veut dire que d'une part le modèle n'a aucune idée de ce à quoi ressemble l'interface, quels en sont ses composants, etc. Le modèle est complètement indépendant de l'interface. D'autre part, la vue n'a aucune idée de la logique de l'application. Autrement dit la vue est stupide, elle a seulement pour rôle d'afficher ou de faire ce que lui dit le contrôleur.
Donc tous les échanges se font via le contrôleur. Lui seul est autorisé à parler avec la vue et avec le modèle.
Comme le suggère le schéma ci-dessus, le contrôleur s'adresse directement au modèle et à la vue. Il peut leur demander ce qu'il veut. Comme sur la route, on peut aller des pointillés vers la ligne pleine mais pas dans l'autre sens.
Mais alors que fait-on si le modèle a de nouvelles données à faire afficher sur l'interface ? Et comment fait-on si la vue a besoin d'informer le contrôleur que l'utilisateur a touché l'écran ? Le modèle et la vue ont-ils le droit de s'addresser au contrôleur ?
La réponse est oui... mais pas n'importe comment ! Et nous allons voir tout au long de ce cours et des suivants quels sont les moyens qu'ont le modèle et la vue de s'addresser au contrôleur.
Mettre en place le MVC dans notre projet
C'était pas mal de théorie mais cela était nécessaire parce que le MVC est vraiment central en iOS. Mais maintenant place à la pratique ! Nous allons finir de préparer notre application en structurant nos fichiers.
Nous allons créer trois groupes : Model, View et Controller.
Remplissons maintenant nos groupes :
Le Model ne contient rien pour le moment. Nous le remplirons dès le prochain chapitre.
Le Controller contient le fichier
ViewController.swiftque nous a déjà fourni Xcode.La View, c'est ce qu'on voit, donc on y place le fichier
Main.storyboarddans lequel nous allons construire notre interface.
Une fois tout cela effectué, votre architecture de dossier doit ressembler à ceci :
Le plan de ce cours
Notre application est fin prête et nous allons pouvoir nous attaquer au coeur de celle-ci dans de bonnes conditions.
Un des avantages du modèle MVC, c'est que l'on peut travailler sur chaque partie indépendamment des autres. Et c'est ce que nous allons faire dans la suite de ce cours en suivant le plan :
Partie 2 : Modèle
Partie 3 : Vue
Partie 4 : Contrôleur
En résumé
Le patron de conception MVC signifie Modèle Vue Contrôleur. Il permet de diviser son programme en trois parties indépendantes :
Le modèle : la logique de l'application.
Le contrôleur : interprète et formate les informations du modèle pour les passer à vue.
La vue : l'interface de l'application.
Le modèle et la vue ne peuvent JAMAIS communiquer.
