vue passive et logique d'affichage

Question

Dans MVC et MVP et les schémas similaires, il y a souvent l'approche de la «vue passive» qui est aussi stupide (contient aussi peu de logique) que possible. Cela devrait faciliter les tests unitaires et créer une séparation plus nette de la vue et du modèle. Je sais que ces modèles ont des saveurs très différentes et surtout la compréhension de MVP semble différer d'un article à l'autre. Par conséquent, ma question n'est pas "comment puis-je implémenter ce modèle correctement". Je veux améliorer la vue et la séparation des modèles et améliorer la testabilité de l'application. Par conséquent, je voudrais aller pour une vue passive. Mais ma question est, où mettriez-vous une logique qui est clairement liée à la vue? comme un textviewer devrait faire défiler le texte lorsque la barre de défilement est déplacée. voulez-vous mettre la logique pour cela dans le présentateur? Supposons que le visualiseur de texte possède des fonctionnalités étendues. comme définir des marques sur les passages de texte. La logique pour cela a clairement un sens à mettre dans le Présentateur. Cependant, s'il est mélangé avec toute la logique 'directe' de la vue (comme le défilement du texte), le Presenter pourrait devenir très grand, ce qui n'est pas vraiment un beau design. Donc, ma question est de savoir où mettre la logique d'affichage d'une vue passive et quelle fonctionnalité à mélanger dans le présentateur.

Merci!

Answer 1

Je mettrais la logique de barre de défilement dans le présentateur si elle a besoin d'aller chercher plus de données du modèle lorsque l'utilisateur défile. Même si ce n'est pas le cas, la vue devrait informer le présentateur.

Parfois, l'API GUI gère le défilement par elle-même. Si c'est le cas, tout ce que vous pouvez faire est de notifier un bout dans le présentateur (qui ne fait rien). La vue n'a aucune idée de ce qui est important pour le présentateur.

Le présentateur ne doit pas nécessairement être une seule classe monolithique. De préférence, vous regrouperiez différents objets pour différentes responsabilités. C'est vraiment bon du point de vue du test, où vous pouvez simuler tous les objets que vous ne testez pas actuellement.