MVC Model - Le contrôleur doit-il accéder directement aux contrôles de la vue ?

Question

J'apprends le développement iOS et ce que j'ai trouvé dans les tutoriels et les livres est que la couche contrôleur a généralement accès aux contrôles de la vue directement (champs de texte, étiquettes, etc.). Considérons un tel exemple :

Supposons que View a une étiquette appelée lblResult et un champ de texte appelé txtDataToAnalyze . Puis, dans l'interface du contrôleur, nous avons quelque chose comme ça :

@property (nonatomic, retain) IBOutlet UILabel* lblResult;
@property (nonatomic, retain) IBOutlet UITextField* txtDataToAnalyze;

et quelques @synthesize dans le fichier d'implémentation.

J'ai une certaine expérience du développement de JavaSwing, où la plupart des pensées que j'écris sont manuelles, sans aucun constructeur d'interface graphique, et ce que je fais habituellement dans MVC est d'accéder aux contrôles de la vue via getters/setter. Par exemple : void setResult(String resString); o String getDataToAnalyze(); . De cette façon, le contrôleur ne connaît que qué éléments d'information sont affichés dans la vue, et non pas cómo sont affichés. Je pense que c'est plus flexible (il est plus facile de changer la couche d'affichage plus tard).

Je sais que iOS a des règles spécifiques, qu'il a introduit des fichiers XIB/NIB, etc. et que mes doutes sont peut-être complètement inutiles dans le cas du développement d'un iPhone/iPad. Mais je vais écrire une application plus sérieuse pour iOS (en fait, la "réécrire" à partir de Java Swing) et c'est pourquoi je voudrais vous poser la question :

Pensez-vous que je doive changer ma façon de penser et m'habituer à cette nouvelle approche (pour moi) (fichiers xib, création d'une interface utilisateur graphique par glisser-déplacer et fournir au contrôleur des informations sur la façon dont les données doivent être affichées dans la vue ) ? ? Avez-vous eu des doutes similaires en commençant avec iOS ?

Answer 1

Réponse courte :

Oui, je pense que vous devez absolument passer un peu de temps à vous habituer à travailler avec Interface Builder (IB) pour créer des NIB et des story-boards et laisser IB créer l'interface. IBOutlet y IBAction des références pour vous pour les contrôles avec lesquels vous devez interagir. Une fois que vous maîtriserez cette technique, vous serez impressionné par votre productivité en matière de génération de code facile à maintenir. Ne rejetez pas l'IB trop rapidement.

Pour ce qui est de permettre au contrôleur d'interagir directement avec la IBOutlet y IBAction références, il s'agit d'une pratique courante pour les interfaces utilisateur simples. Si vous avez des exemples concrets, postez une nouvelle question avec une capture d'écran et nous pourrons vous donner des conseils plus pratiques.

Longue réponse :

1. Une partie de votre question semble être motivée par l'appréhension de voir des contrôleurs de vue qui effectuent une interaction détaillée avec les contrôles d'une vue. En fait, si vous voulez isoler votre contrôleur de certains détails de mise en œuvre de la vue, allez-y, sous-classez la vue et mettez-y les éléments spécifiques à la vue. IB peut s'interfacer avec les sous-classes de contrôleurs de vues ainsi qu'avec les sous-classes de vues. Vous pouvez donc utiliser IB tout en isolant votre contrôleur de vue de certains de ces détails de mise en œuvre.

   Personnellement, je ne fais cette sous-classification que pour les éléments suivants UIView lorsque la vue atteint un certain seuil subjectif de complexité (par exemple, pour moi, ce seuil est lorsque je me retrouve à faire des animations compliquées, comme l'utilisation de CADisplayLink ; les reconnaissances de gestes compliquées, etc.) Je sous-classe également les sous-vues qui sont des entités logiques à part entière (par ex. UITableViewCell o UICollectionViewCell ). Mais pour les vues simples où j'interagis avec mon modèle pour définir les propriétés d'un contrôle, interagir avec des champs de texte, etc., je pense que mettre cela dans le contrôleur de vue est bien. Ceci étant dit, si j'ai beaucoup de code spécifique à la vue dans mon contrôleur qui n'a rien à voir avec l'intégration de mon modèle avec ma vue, alors commencez à sous-classer l'élément UIView et déplacer le code de la vue seulement dans ce dernier.

2. Votre question porte implicitement sur la notion de construction programmatique de vues plutôt que sur l'utilisation de NIBs/storyboards. À mon avis, l'utilisation d'Interface Builder (IB) pour construire votre interface utilisateur est beaucoup plus facile à développer et à maintenir. Il pourrait y avoir une certaine valeur pédagogique à faire un projet de test où vous construisez vos vues par programme, afin que vous compreniez vraiment ce qui se passe, mais après cela, je pense que vous graviterez rapidement vers les storyboards. Et vous aurez de nombreuses occasions d'écrire votre propre code non-IB lorsque vous commencerez à faire des choses qui dépassent les capacités des contrôles IB standard (par exemple, des vues de conteneurs personnalisées compliquées, etc.) Il y a certainement des personnes qui préfèrent développer des vues par programme, mais je ne pense pas que vous puissiez battre la vitesse de développement et la facilité de maintenance des interfaces utilisateur générées par IB.

Answer 2

En général, le contrôleur ne connaît pas la vue, mais la vue connaît le contrôleur.

Le livre du gang des quatre dit :

" MVC " vous permet également de modifier la façon dont une vue répond aux entrées de l'utilisateur sans changer sa présentation visuelle. Vous pouvez, par exemple, modifier la façon dont elle réagit au clavier ou lui faire utiliser un menu contextuel au lieu des touches de commande. MVC encapsule le mécanisme de réponse dans un objet contrôleur. Il existe une hiérarchie de classes de contrôleurs, ce qui permet de créer facilement un nouveau contrôleur en tant que variation d'un contrôleur existant.

Une vue utilise une instance d'une sous-classe de contrôleur pour mettre en œuvre une stratégie de réponse particulière. Pour mettre en œuvre une stratégie différente, il suffit de remplacer l'instance par un autre type de contrôleur. Il est même possible de modifier le contrôleur d'une vue au moment de l'exécution pour permettre à la vue de changer la façon dont elle répond aux entrées de l'utilisateur. Par exemple, il est possible de désactiver une vue pour qu'elle n'accepte aucune entrée, simplement en lui donnant un contrôleur qui ignore les événements d'entrée.

La relation Vue-Contrôleur est un exemple du modèle de conception Stratégie (315). Une stratégie est un objet qui représente un algorithme. Il est utile lorsque vous voulez remplacer l'algorithme de manière statique ou dynamique, lorsque vous avez beaucoup de variantes de l'algorithme, ou lorsque l'algorithme a des structures de données complexes que vous voulez encapsuler."