MVC dans une application basée sur un document Cocoa

Question

Je suis en train de refactoriser et de réorganiser mon application pour le moment. J'ai réalisé qu'une partie de la séparation entre les modèles et les vues, et leurs contrôleurs a diminué et je souhaite faire un peu de nettoyage.

J'ai plusieurs classes clés utilisées dans mon application: NSPersistentDocument, NSWindowController et une classe de modèle.

La classe NSPersistentDocument agit en tant que "model-controller"; il possède une instance de la classe modèle et gère toutes les interactions avec le modèle.

La classe NSWindowController agit en tant que "view-controller"; il possède la fenêtre principale et gère les interactions des vues dans la fenêtre principale. Cette classe est également le propriétaire du fichier nib dans lequel la fenêtre est définie.

Le problème que je vois ici est que je n'ai pas de réel "contrôleur". Ma conception actuelle oblige le contrôleur de modèle et le contrôleur de vue à se connaître. Il n'y a pas d'objet méditant entre les deux, et à cause de cela, mon modèle et ma vue ne sont pas clairement séparés, ce qui rend le support de plusieurs vues ou modèles un problème. Je voudrais déplacer la fonctionnalité de mes deux contrôleurs existants dans une nouvelle classe de «contrôleur» qui agirait comme un contrôleur entre le contrôleur de modèle et le contrôleur de vue. En fin de compte, ce n'est encore que le modèle de conception MVC, avec juste un peu plus de structure.

Cependant, j'ai de la difficulté à trouver comment cela pourrait s'intégrer dans l'architecture d'application basée sur les documents de Cocoa.

La plus grande question que j'ai est où et comment ce nouvel objet de contrôleur serait créé? Comment cela s'intègre-t-il dans l'architecture de Cocoa? Est-ce que je me bats contre l'architecture de Cocoa, et y a-t-il une meilleure façon de le faire?

Merci.

Answer 1

Très bon instinct d'avoir un "contrôleur de modèle" et un "contrôleur de vue". C'est une très bonne taxonomie mentale sur la façon dont les M et les V s'accrochent habituellement. Mais vous pouvez toujours avoir le "C" pur dans le MVC pour lier toute l'opération ensemble, comme vous le notez. Si vous parlez d'un contrôleur, pour l'application: Pensez au contrôleur (big-C) comme étant la chose qui sort de la fonction main() de votre application - dans les tutoriels Cocoa plus anciens, cet objet est souvent appelé AppController. Il peut s'agir du délégué de UIApplication ou non, mais si ce n'est pas le cas, vous devez envisager de créer un tel contrôleur principal dans la méthode applicationDidFinishLaunching: du délégué de l'application dans votre projet. Ce AppController peut ensuite configurer (et posséder) les objets du modèle et configurer (et posséder) le contrôleur de vue racine, à partir de laquelle votre interface utilisateur ressorts.

Si vous parlez d'un composant de médiation qu'il y a plusieurs instances de, une pour chaque "paire" modèle/vue dans une architecture de document, alors faites juste quelque chose comme ça. DocumentController est le genre de nom que vous voulez, bien que Cocoa en ait déjà un qui reflète ou non le type de fonctionnalité dont vous avez besoin. "DocumentManager" est un autre nom de candidat.

Answer 2

Il semble que vous deviez prendre une copie de Cocoa Design Patterns, répond à ces questions, puis à certaines d'entre elles.

Le chapitre 2 traite du modèle MVC à l'aide d'un ArrayController en tant que contrôleur de modèle (plutôt que du contrôleur de modèle de document persistant que vous utilisez).