MVC avec le cacao/objective-c

Question

J'ai un fond de j2ee fort, et j'essaye de passer à l'objectif-c pour une certaine programmation de bureau/iphone. J'ai utilisé de nombreux frameworks java web avec mvc en tête, spring et struts ecc ... donc j'ai l'habitude d'avoir une servlet ou un contrôleur qui passe des attributs aux pages jsp, ce qui est la vue. Dans les pages jsp avec jstl, vous pouvez appeler cet attribut et le rendre en vidéo. De cette manière, le contrôleur et la vue sont (en théorie) clairement séparés.

Avec xcode, je peux facilement reconnaître le contrôleur et la vue construite avec IBuilder. Tout le tutoriel que j'ai trouvé, montré le contrôleur qui vont et changer directement les étiquettes ou les champs de texte.

Alors mes deux questions:

1. me semble qu'il n'y a pas de séparation entre les deux (contrôleur et vue), où je me trompe dans tout cela?
2. Y at-il un moyen pour un contrôleur d'emballer tous les objets dans un type de contexte d'une manière j2ee et que la vue lise ce contexte?

grâce Leonardo

Answer 1

Dans la plupart des exemples que vous avez-vous lu vu probablement quelque chose comme ceci:

[myTextfield setStringValue:myString]; 

maintenant dans ce cas que le contrôleur est mise à jour le champ de texte directement, mais comme myTextField est habituellement un IBOutlet il peut être tout textfield dans votre vue, ou même nul. Tout à fait possibiy il n'a même pas besoin de savoir que c'est un NSTextfield juste qu'il répond à une méthode setStringValue.En ce sens, il y a une séparation entre le contrôleur et la vue. Maintenant, dans vos commentaires ci-dessus, vous étiez préoccupé par la séparation des responsabilités au sein de MVC, mais n'a pas beaucoup mentionné le modèle. Avec les liaisons Cocoa, vous pouvez vous lier directement aux keypaths du modèle, dans ce cas le modèle ne doit rien savoir du tout de la vue. MVC est un peu un concept ambigu, sans définition précise. Cela peut signifier différentes choses pour différentes personnes. Pour moi, cela signifie que la vue a une connaissance du contrôleur (à travers des prises ou des liaisons) une connaissance limitée du modèle (à travers des liaisons). Le contrôleur a une connaissance complète du modèle et une connaissance limitée de la vue (à travers les points de vente). Enfin le modèle n'a aucune connaissance de la vue et idéalement aucune connaissance du contrôleur. En ce qui concerne votre deuxième question, je n'utilise pas j2ee, mais je pense que vous pouvez réaliser ce que vous voulez en mettant votre contrôleur à jour un contexte ivar (probablement un NSDictionary) puis à votre avis se lier à ce contexte avec un keypath. Cependant, il n'y a pas vraiment besoin de tout emballer, les reliures sont très polyvalentes et vous pouvez vous lier à n'importe quelle propriété.

Answer 2

Je ne comprends pas votre deuxième question (je ne l'ai jamais utilisé J2EE), mais je pense que je peux faire quelques progrès répondre à votre première.

Le cacao n'applique pas MVC; il l'encourage fortement - surtout pour les projets plus importants. Considérons un exemple de programme, un qui a un NSTableView lié à un NSArrayController. Dans ce cas, le NSTableView est clairement l'affichage (il a le mot "view" dans son nom) et NSArrayController est clairement le contrôleur (il a le mot "controller" dans son nom).

Le modèle est un NSArray que NSArrayController connaît, mais vous n'interagissez probablement pas directement avec ce modèle. Vous demanderez plutôt à NSArrayController de manipuler son modèle en envoyant des messages addObject: et removeObject: au contrôleur de tableau (et non au tableau lui-même). Lorsque vous faites cela, NSArrayController effectuera une modification dans NSTableView via des liaisons. Encore une fois, vous ne demandez jamais à NSTableView de faire quoi que ce soit.

Donc, vous ne parlez jamais à la vue et vous ne parlez jamais au modèle. Tout ce que vous voulez arriver passe par le contrôleur.

MVC. QED.

Bien sûr, peut-être la façon dont votre projet fonctionne, la vue devrait être son propre contrôleur. Le monde ne se terminera pas, bien que vous pourriez trouver un peu plus difficile d'aller à l'encontre du cadre. Mais vous devriez toujours essayer d'utiliser la meilleure approche pour le travail en cours au lieu d'insister sur une sorte de pureté de modèle de conception.