Android MVP: Qu'est-ce qu'un Interactor?
qu'est Ce qu'un Interacteur? Comment s'intègre-t-il dans la conception MVP? Quels sont les avantages et les inconvénients de l'utilisation d'un interactor vs de mettre le code interactor dans le présentateur?
4 réponses
MVP existe pour s'attaquer au problème de L'activité de Dieu (une activité/Fragment qui a beaucoup trop de lignes).
alors que ce n'était pas obligatoire (vous pouvez coder dans n'importe quel modèle que vous voulez), de nombreux développeurs conviennent que MVP est adapté pour Android. Il rend votre code source plus propre, testable, maintenable et robuste.
vous pouvez penser à un interactor comme votre "Model/Controller". Un interactor récupérera les données de votre base de données, des services web, ou toute autre source de données. Après l'obtention de les données, l'interacteur va envoyer les données pour le présentateur. Par conséquent, apporter des changements à votre UI.
les avantages d'utiliser interactor dans une classe séparée est qu'il va découpler votre classe, ce qui le rend plus propre et testable. Bien sûr, vous pouvez mettre l'interactor dans votre classe de présentateur, mais à quoi bon? Les inconvénients de mettre l'interactor dans votre présentateur est il rendra votre classe de présentateur plus grand et relativement plus difficile à lire et à gérer.
mise à jour: De bien sûr c'est juste une simplification, si vous voulez creuser plus profond que vous pouvez voir fernando cejas blog ou le blog d'antonio leiva
Interactor est une classe qui sépare la couche domaine de la couche Présentation. En termes simples, il fournit la façon d'écrire la logique des affaires dans séparément que le code qui est utilisé pour manipuler L'UI (en liant les données à L'UI/ animate / navigation).
donc Interactor est médiateur entre le Presenter/ViewModel et le motif du dépôt.
Je n'ai pas utilisé L'Interactor pattern dans MVP, mais je l'ai utilisé dans MVM. Interactor peut être utilisé indifféremment pour les UseCases.
par exemple, prenons cas d'utilisation de catégories de fetching pour afficher dans la liste.
- Voir (Activité/Fragment) va appeler Présentateur/ViewModel de la méthode pour obtenir categoryList.
- alors le présentateur appellera la méthode d'interactor pour obtenir categoryList
- Interactor appellera la méthode (Categorepository) du dépôt pour obtenir categoryList
- le dépôt aura la logique de décider s'il faut récupérer les catégories du Service Web (données à distance Source) ou à partir de la mémoire DB (Local Data Source) ou de cache (temporary storage - peut être variable dans la classe de dépôt).
- le dépôt retournera categoryList (tiré de la source de données sélectionnée) à Interactor
- Interactor va soit traiter sur categoryList (certains formatage etc) et l'envoyer au présentateur. Interactor peut envoyer directement la liste au présentateur si aucun traitement n'est nécessaire
- le présentateur appellera la méthode de View avec categoryList comme paramètre
- Affichage montrera categoryList avec ou sans Animation
notez que dans ce processus Interactor peut être évité ainsi au lieu d'utiliser le flux de données comme ceci Repository->Interacteur->Présentateur, la communication peut être passé par Repository->Présentateur de cette façon. Ici, le présentateur fera aussi partie de la couche Présentation/domaine. Comme je l'ai dit plus haut, Interactor agit comme séparateur de ces deux couches.
ce sont quelques des blogs écrits de façon concise pour expliquer ce concept de référence
- clean-architecture-avec-mvvmi
- android-mvp-architecture-extension-avec-interacteur
- architecture-android-le-clean -
j'espère que cela va vous aider dans la compréhension du rôle de l'Interacteur dans une meilleure façon
Interacteur contient le cas d'utilisation de l'application, ce qui signifie qu'il contient tous les implémentations pour le domaine d'activité du projet.
voici un article très bien organisé sur architecture des Applications Android, en utilisant le modèle MVP., je vous recommande fortement d'étude.
J'ai aussi créé une application android appelée JuicyInsta, à l'aide de l'API MVP pattern et Instagram, qui est partagé ici sur github.
personnellement j'utilise View, Present et Interactor qui pour moi est différent du modèle.
Vous pouvez penser à un Interacteur comme une classe avec des méthodes utiles pour récupérer les données à partir de la base de données, serveur, etc. Après avoir obtenu les données, vous pouvez remplir votre modèle dans L'Interactor et le rendre au présentateur.
E. G. Vous pouvez avoir un Loginininteractor qui crée un Asynctask pour authentifier l'utilisateur et ensuite peupler le modèle UserModel les données reçues.