A quoi ressemble l'organisation de classes MVC pour plusieurs vues et contrôleurs?

Question

L'idée de MVC lui-même me semble claire, mais j'ai du mal à comprendre comment le concept 'évolue' vers plusieurs vues et contrôleurs.

Il semble que Cocoa considère l'approche du contrôleur comme le «standard» entre le modèle et la vue. Comment l'application pourrait-elle être organisée et fonctionner en cas de vues multiples? Si un contrôleur est associé à chaque vue, l'application principale doit-elle garder une trace de tous les contrôleurs qu'elle génère, ou chaque contrôleur doit avoir des contrôleurs «imbriqués» qu'il instancie, par ex. une application créerait une fenêtre, la fenêtre créerait une barre d'outils, etc?

Et si l'application entière devait fonctionner avec le même modèle, ou décomposeriez-vous les modèles en plus petits?

Il semble que ce que je demande vraiment, c'est comment vous pourriez diviser une application multi-fenêtre/vue en blocs logiques tout en conservant la structure modulaire MVC. J'ai essayé de regarder le code de l'application iPhone WordPress ainsi que Adium mais les deux semblent avoir une base de code relativement importante dans laquelle je me perds.

Answer 1

Généralement les contrôleurs sont implémentés hiérarchiquement. Par exemple, dans l'architecture Cocoa Document standard, vous avez un NSDocumentController qui gère plusieurs instances de NSDocument. Chaque instance de NSDocument gère une ou plusieurs instances de NSWindowController et chaque instance de NSWindowController peut gérer une ou plusieurs instances de NSViewController. Lorsque vous descendez la hiérarchie, les contrôleurs deviennent plus spécifiques et plus précis dans leurs responsabilités. En termes d'accès au modèle, Cocoa a plusieurs modèles tels que les modèles de délégué et de source de données que vous pouvez utiliser pour permettre à la vue de dessiner sans que la vue ait besoin de connaître quoi que ce soit sur le modèle lui-même.

Généralement, l'application aurait un seul modèle unifié, à moins qu'il soit logique d'avoir différents modèles (par exemple, si vous aviez besoin de votre application pour éditer différents types de document).