Modèles de conception pour Cocoa MVC et MVVM

Les modèles de conception rendent le code de votre application plus modulaire et plus indulgent en ce qui concerne les corrections de bugs et les modifications. Dans cet article, vous en apprendrez davantage sur les modèles de conception MVC (Model-View-Controller) et MVVM (Model-View-ViewModel)..

Bien que les modèles de conception (également appelés modèles architecturaux) soient la clé du développement d'applications Cocoa Touch évolutives, il existe de nombreuses controverses autour du choix du modèle architectural le mieux adapté à votre application.. 

Consultez ces articles récents de Bart Jacobs sur MVC et MVVM pour davantage de perspectives sur ces modèles de conception et sur le choix entre eux..

• 

  Pourquoi MVC pourrait ne pas être le meilleur modèle pour les applications Cocoa

  Model-View-Controller (MVC) est un modèle de développement logiciel répandu. Découvrez ce qu'est MVC et pourquoi ce n'est peut-être pas la meilleure solution pour les développeurs Cocoa.
• 

  Mettez vos contrôleurs de vision au régime avec MVVM

  Découvrez une alternative au modèle MVC: Model-View-ViewModel. Je vais vous montrer comment MVVM peut résoudre certaines des lacunes de Model-View-Controller.

La collection d'objets d'un certain [motif architectural] dans une application est parfois appelée couche, par exemple couche modèle. - Pomme

Sans plus tarder, examinons quelques-uns des modèles de conception que vous pourrez utiliser dans votre prochaine application..

MVC (Model-View-Controller)

C'est le motif le plus couramment utilisé dans le développement de Cocoa Touch, et c'est aussi mon préféré. Ce modèle de conception trie efficacement votre code en trois catégories (ou couches): le modèle, la vue et le contrôleur..

Comment ça marche et pourquoi devrais-je l'utiliser??

Avec ce motif de conception, vous pouvez modifier un calque sans affecter les autres calques du motif. Par exemple, si vous devez modifier la base de données, vous devez simplement supprimer le modèle et le remplacer sans avoir à modifier la vue ou le contrôleur. Ou si vous souhaitez modifier l'apparence d'une vue, vous n'avez pas à vous soucier de modifier le code de la base de données. Cela s'appelle "séparation des problèmes" et facilite le débogage, la maintenance et la réutilisation de votre code..

En outre, il s'agit du modèle de conception recommandé par Apple et qui constitue une norme dans la communauté de développement iOS. Si vous débutez, je vous recommande vivement de vous en tenir à ce modèle. Vous pouvez essayer différents modèles de conception plus tard dans votre carrière de développement de cacao.

Couches et Responsabilités

Examinons de plus près les différentes couches de ce motif et la responsabilité de chacune d’elles. Voici un diagramme rapide des interactions entre les couches:

Le modèle de conception MVC sépare chaque partie de votre code en une des trois parties suivantes: le modèle, la vue et le contrôleur.. 

• Modèle: Cette couche est seulement responsable des données et de leur forme telles qu'elles apparaissent dans votre application. La couche contrôleur peut modifier les données de l'application en notifiant le modèle. Le modèle n'est pas responsable de quoi que ce soit d'autre, y compris la façon dont les données sont présentées à l'utilisateur, ou qui ou qui utilise les données.
• Vue: La vue est responsable de la représentation des données-seulement comment l'utilisateur voit et interagit avec les données. Cela peut inclure des cellules réutilisables, des tables et d'autres éléments d'interface utilisateur qui ignorent tout des données et de leur traitement. Les données sont fournies aux éléments de vue par le contrôleur.
  
• Manette: Le contrôleur est la star du spectacle. Il apporte les données du modèle, puis les transmet à la vue pour les afficher à l'utilisateur. C’est la seule couche entre le modèle et la vue, ce qui peut entraîner des problèmes, que nous examinerons plus loin dans cet article. Le contrôleur est généralement implémenté dans ViewController.swift,et il est responsable d'écouter et de changer le modèle au besoin.

Une chose à garder à l'esprit est qu'il ne faut pas confondre trop de responsabilités dans l'une ou l'autre de ces couches car cela irait à l'encontre du but du motif de conception.!

En outre, si vous ne maintenez pas les connexions entre les couches nettes et claires, vous obtiendrez une application désordonnée et indescriptible, malgré l'utilisation du modèle de conception MVC! En particulier, assurez-vous de ne pas laissez la vue et le modèle communiquer directement. Ces interactions doivent se produire uniquement via le contrôleur.

MVVM (Model-View-ViewModel)

Bien que le modèle de conception Modèle-Vue-Contrôleur soit assez commun et qu'il fonctionne dans la plupart des cas, il présente son propre ensemble de défis et d'inconvénients. Pour cette raison, nous avons un autre modèle de conception appelé MVVM, qui signifie Model-View-ViewModel..

MVC est génial, alors pourquoi ai-je besoin de MVVM??

Eh bien, il y a un problème majeur dont vous devriez être au courant. Comme vous l'avez vu dans la section précédente, la couche Contrôleur est la seule couche entre la vue et le modèle. Il n'est donc pas surprenant que les utilisateurs abusent de cette couche et lui donnent rapidement trop de tâches à faire. Cela peut sembler la chose la plus facile à faire à ce moment-là, car cela évite de changer les autres couches, mais finit par conduire à un contrôleur saturé et à un code difficile à gérer..

Cela a conduit à donner à MVC le surnom fantaisiste "Massive-View-Controller" dans certains cercles.

Le modèle architectural MVVM, emprunté par Microsoft aux développeurs Cocoa, peut aider à lutter contre ce problème de contrôleurs de vue volumineux. Bien que cela ne soit pas aussi courant dans le développement iOS que MVC, il est de plus en plus utilisé pour compenser les faiblesses de MVC..

Couches et Responsabilités

Examinons les différentes couches et leurs responsabilités dans MVVM. (Vous devriez probablement noter que dans la communauté Cocoa, il n'y a pas de directives formelles sur l'utilisation de ces couches.) 

Voici un rapide diagramme montrant les couches de ce motif architectural et leurs connexions les unes aux autres.

Si vous y réfléchissez, vous verrez que même si les vues et les contrôleurs sont des calques distincts dans le modèle de conception MVC, ils sont très étroitement couplés. Donc, dans MVVM, nous prenons simplement la vue et le contrôleur et les combinons en une couche. 

Comparons chaque couche à sa contrepartie dans le modèle MVC. 

• (Voir) Contrôleur: Cette couche, généralement connue sous le nom de View, est étroitement connectée au contrôleur. A tel point qu'ils ne sont même pas séparés en différentes couches! La vue seulement communique avec le contrôleur, mais le contrôleur communique avec le ViewModel et la vue. La vue et le contrôleur effectuent les mêmes tâches que dans MVC, à la différence que certaines tâches attribuées au contrôleur (dans MVC) sont désormais gérées par une couche intermédiaire, le ViewModel, afin d'éviter toute utilisation abusive du contrôleur. La vue gère toujours l'affichage des données à l'utilisateur et le contrôleur répond aux événements de l'utilisateur et communique avec le reste des couches du motif..
• ViewModel: En réalité, cette couche ne contient aucune "vue", mais gère plutôt la logique derrière l'affichage des vues, généralement appelée logique de présentation. Cela comprend la création de formatages personnalisés et le traitement de chaînes à afficher, ainsi que le calcul exact des chiffres à afficher à l'utilisateur en fonction des données de la couche Modèle. 
  
• Modèle: Le modèle n'est pas très différent de la couche modèle dans le modèle MVC. Comme nous l'avons vu précédemment, le modèle seulement gère les données et les modifie si elles reçoivent des mises à jour de la couche ViewModel. Cela fait ne pas savoir qui utilise les données, ce qu'elles en font ou comment l'utilisateur les voit.

Comme vous l'avez vu précédemment, vous ne devez pas associer les responsabilités de l'une de ces couches, car cela pourrait entraîner une complexité accrue du code de votre application, rendant l'utilisation de tout modèle de conception superflue..

Conclusion

J'espère que vous avez aimé en apprendre davantage sur ces modèles de conception fondamentaux pour iOS. Espérons que vous avez acquis une meilleure compréhension des modèles de conception MVC et MVVM et que vous êtes suffisamment confiant pour les utiliser dans vos futures applications.. 

Bien entendu, le modèle architectural que vous utilisez pour votre application dépend entièrement du type d'application que vous essayez de développer. Toutefois, si vous débutez dans le développement iOS, je vous recommande fortement de vous en tenir au modèle de conception MVC, car il reste le plus courant dans le développement de Cocoa..

Pendant que vous êtes toujours là, assurez-vous de consulter certains de nos autres tutoriels et articles ici sur Envato Tuts+!