Reprendrais tu un peu d’acronymes pour saupoudrer sur ton apprentissage de Swift ? Je voulais aborder le sujet de l’architecture concernant la construction de ton application mobile.

Quand, aujourd’hui, la majorité des applications (pas que mobiles) se basent sur une architecture MVC (Modèle – Vue – Contrôleur), il est intéressant de se poser la question de l’architecture pour une application mobile.

Dans la création du cahier des charges, nous avons abordé le point technique. C’est maintenant que nous allons choisir une architecture pour notre application. Plutôt MVC, MVP ou MVVM ? Nous allons voir en détails leurs avantages et leurs inconvénients. Ainsi, tu pourras faire le meilleur choix pour la création de ton application mobile.

Dans chacun des cas, la vue et le modèle ont le même rôle :

  • Le Modèle va communiquer avec la base de données
  • La Vue représente tous les éléments qui composent la vue. C’est le résultat graphique de l’application

Architecture MVC

L’architecture MVC représente le triplet Model – View – Controler.

Ici, le Modèle va contenir toute la logique ainsi que les appels à la base de données.

Le Contrôleur est l’élément qui fait l’intermédiaire. Il gère les interactions entre l’utilisateur et le système (la vue et le modèle). Ici, tous les éléments interagissent plus ou moins directement entre eux. Ainsi, la vue et le modèle communiquent et se renvoie des informations.

Architecture MVVM

L’architecture MVVM est quant à elle basée sur le principe Model – View – ViewModel.

Le ViewModel étant le composant central qui agit comme un intermédiaire entre le modèle et la vue. Il contient les données, la logique de présentation et la logique métier. La vue reflète donc simplement l’état du ViewModel. Alors que le modèle interagit avec les données.

Contrairement au modèle MVC, MVVM permet de séparer clairement les interactions entre la vue et le modèle. Par exemple, si le modèle change, la vue ne changera pas forcément. Et inversement. Ainsi, les tests unitaires sont donc plus faciles à réaliser car ils n’impliquent pas la vue.

Architecture MVP

Ici nous parlons de l’architecture Model – View – Presenter.

Ici, le modèle représente les données et la logique métier (comme pour l’architecture MVC). Le présentateur agit comme intermédiaire entre la vue et les données. Il met donc à jour le modèle et la vue séparément, en fonction des interactions de l’utilisateur.

Comparaison

MVCMVVMMVP
Avantages– Facilite la maintainabilité et la gestion du code
– Prend en charge les requêtes asynchrones
– Une modification n’affecte pas l’application entière
– Architecture qui a fait ses preuves
– Composants fonctionnent indépendamment
– Code facilement réutilisable
– Facile pour les tests unitaires
– Très utilisé pour les applications mobiles
– Plusieurs vues peuvent être gérées dans une ViewModel
– Bonne séparation des composants
– Facile à tester
– Permet de faire du code propre
Inconvénients– La vue peut devenir complexe
– Le contrôleur peut devenir lourd et difficilement maintenable
– Difficile de modifier certaines fonctionnalités car couches étroitement liées
– Tests unitaires difficiles
– Plus complexe à comprendre
– Debogage plus difficile car liaison de données complexes
– Moins bien utilisable pour les petites applications
– La vue peut devenir complexe
– La logique de présentation est souvent dupliquée dans plusieurs présentateurs
– Facile pour les tests unitaires mais le lien entre vue et présentateur peut les rendre difficiles
Quand l’utiliser ?– Pour les petits projets
– Projet ayant besoin d’une vue simple
– Projet rapide
– Ne suit pas le principe de modularité et responsabilité unique
– Plutôt pour les gros projets
– Pour les modèles de données complexes
– Quand le design et la logique peuvent être séparés
– Suit le principe de modularité et responsabilité unique
– Pour les projets simples et complexes
– Bonne collaboration entre les différentes parties de l’équipe
– Suit le principe de modularité et responsabilité unique

Mon choix pour mon projet

Après cette présentation complète, j’ai envie de te parler de mon projet d’application mobile. Que vais-je finalement choisir ?

Pour rappel, je compte créer une application mobile iOS qui permettra à ses utilisateurs d’apprendre et de s’entraîner sur Swift.

Bien que mon application soit relativement « petite », je choisis de partir sur une architecture MVVM. En effet, je viens du monde du développement web et j’ai déjà expérimenté l’architecture MVC. Bien qu’elle me satisfasse grandement et que j’y sois habituée, j’aime apprendre de nouvelles choses. Ça sera donc l’occasion pour moi de mettre en pratique une nouvelle forme d’organisation. De plus, je m’intéresse au clean code et le fait que MVVM rende si simple les tests unitaires me conforte dans mon envie d’apprendre à l’utiliser. Je me dis également que ça sera une compétence « employable », si je décide d’intégrer une entreprise avec un gros projet, qui utilise ce type d’architecture.


Maintenant que tu en sais plus sur les différentes formes d’architectures, tu peux mettre en place ton application 🥳

Si tu veux d’autres points de vue sur le sujet, voici un lien très utile qui te donne d’autres informations sur le sujet.

Dis nous en commentaire quelle architecture tu as choisi pour ton projet !

Si tu as aimé cet article, partage le 🫶