Quel est le modèle MVP d’Android ? Quelle est la différence avec les fonctions ordinaires de gestion des événements d’écriture ?
MVP est-il simplement une classe de présentateur supplémentaire pour contenir l'objet de vue Android, traiter les données et actualiser la vue ?
La différence par rapport à l'écriture ordinaire de fonctions de traitement d'événements est-elle que le code de la fonction de traitement d'événements est déplacé dans la classe du présentateur ?
Mais si ce n’est que cette différence, cela ne semble pas avoir quelque chose de spécial. Ne sommes-nous pas tous si abstraits lorsque nous écrivons du code ? En faisant abstraction de la logique métier, pourquoi devrions-nous séparer le concept de MVP ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Personnellement, les avantages sont les suivants :
1. La logique est claire, l'interface appartient à View, et le traitement des données appartient à Presenter Il n'y aura pas d'explosion d'Activité et de Fragment. , et la maintenance et les mises à niveau ultérieures seront également difficiles. Apporte une grande commodité. Quand je regarde le code écrit par d'autres, j'ai surtout peur que la superposition ne soit pas claire et soit très difficile.
2. Les tests sont pratiques. Le présentateur peut être utilisé seul pour les tests. Il n'est pas nécessaire de le lier à la vue pour les tester.
Vous avez raison de dire cela, utilisez le présentateur spécifiquement pour gérer les vues.
Avantages à mon avis :
1. Le présentateur reçoit normalement l'interface d'une vue. Cette application du DIP (Dependency Inversion Principe) nous permet de nous appuyer autant que possible sur l'abstraction, afin que n'importe quelle vue puisse être utilisée tant qu'elle est implémentée. ces interfaces partagent ces logiques de traitement.
2. L'application du SRP (Single Responsibility Principe) peut séparer et découpler la couche logique de traitement des données de la vue
En fait, c'est juste que notre développement est un peu aléatoire. Selon le principe OCP, il est fermé au développement et à la modification d'extensions. Une activité peut avoir une version v1 v2 v3. remplacer le précédent. Repousser le code ou le modifier en fonction du code précédent est un comportement dangereux et inefficace. Si vous utilisez MVP, lorsque vous disposez des versions v2 ou v3, vous avez peut-être ajouté quelques contrôles, ou. réduisez quelques contrôles. Si vous modifiez directement le code précédent à ce moment-là, alors le framework MVP est effectivement inutile, mais si vous développez de manière étendue, ce sera différent, puis écrivez une nouvelle interface. pour hériter de l'interface de la vue d'origine, puis créer un nouveau présentateur pour hériter de l'ancien et y écrire une nouvelle logique, ce qui est pratique pour la maintenance et les tests. Il vous suffit de tester le nouveau code et la stabilité du. Le programme est que le sexe peut être amélioré.
Donc, si vous écrivez selon le modèle MVP, la maintenabilité de votre code deviendra plus forte sans le savoir.