-
Notifications
You must be signed in to change notification settings - Fork 2
MVP
Le modèle MVP (Model View Presenter) est un dérivé du MVC (Model View Controller) bien connu, qui pendant un certain temps gagne de l'importance dans le développement d'applications Android. Il y a de plus en plus de gens qui en parlent, mais très peu d'informations fiables et structurées.
Le modèle MVP permet de séparer la couche de présentation de la logique, de sorte que tout sur le fonctionnement de l'interface est séparé de la façon dont nous le représentons à l'écran. Idéalement, le modèle MVP permettrait d'obtenir cette même logique pour des vues complètement différentes et interchangeables. La première chose à préciser est que MVP n'est pas un modèle architectural, il est seulement responsable de la couche de présentation. Dans tous les cas, il est toujours préférable de l'utiliser pour votre architecture que ne pas l'utiliser du tout.
Dans Android, nous avons un problème découlant du fait que les activités Android sont étroitement couplées à l'interface et les mécanismes d'accès aux données. Nous pouvons trouver des exemples extrêmes tels que CursorAdapter, qui mélangent des adapters, qui font partie de la vue, avec des curseurs, quelque chose qui devrait être relégué aux profondeurs de la couche d'accès aux données. Pour qu'une application soit facilement extensible et maintenable, nous devons définir des couches bien séparées. Que faisons-nous demain si, au lieu de récupérer les mêmes données d'une base de données, nous devons le faire à partir d'un service Web? Nous devrions refaire toute notre vision. MVP rend les vues indépendantes de notre source de données. Nous divisons l'application en au moins trois couches différentes, ce qui nous permet de les tester indépendamment. Avec MVP nous sommes en mesure de prendre la plupart de la logique hors des activités afin que nous puissions le tester sans utiliser des tests d'instrumentation.
Dans une application avec une bonne architecture en couches, ce modèle ne serait que la passerelle vers la couche de domaine ou la logique métier. Si nous utilisions l'architecture propre d'Uncle Bob, le modèle serait probablement un interactor qui implémente un cas d'utilisation. Mais c'est un autre sujet que j'aimerais aborder dans les prochains articles. Pour l'instant, il suffit de le voir comme le fournisseur des données que nous voulons afficher dans la vue.
La Vue, généralement mise en œuvre par une activité (il peut s'agir d'un fragment, d'une vue ... en fonction de la structure de l'application) contiendra une référence au présentateur. Présentateur sera idéalement fourni par un injecteur de dépendance comme Dagger, mais au cas où vous n'utilisez pas quelque chose comme cela, il sera responsable de la création de l'objet présentateur. La seule chose que la vue fera est d'appeler une méthode du présentateur chaque fois qu'il ya une action d'interface (un clic de bouton par exemple).
Le Présenteur est responsable d'agir comme "middle man" entre la vue et le modèle. Il récupère les données du modèle et les retourne formaté à la vue. Mais contrairement au MVC typique, il décide également ce qui se passe lorsque vous interagissez avec la vue.
Séparer l'interface de la logique dans Android n'est pas facile, mais le modèle Model-View-Presenter rend un peu plus facile d'empêcher que nos activités finissent par se dégrader en classes très couplé consistant en des centaines voire des milliers de lignes. Dans les grandes applications, il est essentiel de bien organiser notre code. Sinon, il devient impossible de maintenir et d'étendre l'application.