MVC design en Cocoa - les 3 sont-ils toujours nécessaires? Aussi: conventions de nommage, où mettre contrôleur

Question

Je suis nouveau à MVC bien que j'ai lu beaucoup de documents et d'informations sur le web. Je sais que c'est un peu ambigu et il y a beaucoup d'interprétations différentes des modèles MVC .. mais les différences semblent un peu minimes

Ma principale question est - M, V et C vont toujours être nécessaire pour faire cela correctement? Je n'ai vu personne répondre à cela dans tout ce que j'ai lu. Exemples (je travaille dans Cocoa/Obj-c bien que cela ne soit pas très important)

1) Si j'ai une image simple sur mon interface graphique, ou un champ de saisie de texte qui est juste pour la commodité d'un utilisateur et n'est pas enregistré ou modifié, ces deux seraient V (vue) mais il n'y a pas de M (pas de données et pas de traitement de domaine en cours), et pas de C pour les relier. J'ai juste quelques aspects qui sont "V" - semble bien

2) J'ai 2 fenêtres différentes et visibles qui ont chacune un bouton étiqueté comme "ACTIVATE FOO" - quand un utilisateur clique sur le bouton sur soit, les deux boutons enfoncent et changent pour dire "DÉSACTIVER FOO" et une troisième fenêtre apparaît avec l'étiquette "FOO". Cliquer à nouveau sur le bouton changera le bouton sur les deux fenêtres pour "ACTIVER FOO" et supprimera la troisième fenêtre "FOO". Dans ce cas, mon V se compose des boutons sur les deux fenêtres, et je suppose aussi la troisième fenêtre (peut-être toutes les 3 fenêtres). J'ai certainement un C, mon objet Controller connaîtra ces boutons et fenêtres et obtiendra leurs clics et maintiendra des états génériques concernant les fenêtres et les boutons. Cependant, si j'ai 1 bouton ou 10 bouton, ma fenêtre est appelée "FOO" ou ma fenêtre est appelée "BAR", cela n'a pas d'importance. Il n'y a aucune connaissance de domaine ou de données ici - juste le contrôle des vues. Donc, dans cet exemple, j'ai vraiment "V" et "C", mais pas "M" - est-ce correct?

3) Exemple final, auquel je cours le plus. J'ai un champ de saisie de texte comme vue. Quand je saisis du texte, disons un nombre représentant la gravité, je le garde dans un Modèle qui peut faire des choses comme calculer la physique d'une balle tout en prenant en compte mon paramètre de gravité. Ici, j'ai un V et un M, mais je ne comprends pas pourquoi j'aurais besoin d'ajouter un C - un contrôleur accepterait simplement les signaux de la Vue et les transmettrait au Modèle, et vice versa. Etre comme le C est juste un passthrough pur, c'est vraiment du code "indésirable" et ne rend pas les choses plus réutilisables à mon avis. Dans la plupart des situations, quand quelque chose change, je vais devoir changer le C et le M de manière presque identique. Je me rends compte que c'est probablement l'erreur d'un débutant MVC de penser que la plupart des situations appellent seulement V et M .. me conduit au sujet suivant

4) Dans Cocoa/Xcode/IB, je suppose que mes contrôleurs doivent toujours être un objet instancié dans IB? C'est-à-dire, je pose tous mes composants "V" dans IB, et pour chaque collection d'objets View (choses qui sont liées) je devrais avoir un contrôleur instancié? Et puis peut-être que mes modèles ne devraient pas être trouvés dans IB, et à la place seulement trouvés comme des classes dans Xcode qui se lient avec le code du contrôleur qui s'y trouve. Est-ce exact? Cela pourrait expliquer pourquoi vous auriez un contrôleur qui n'ajoute pas vraiment de valeur - parce que vous gardez cohérent ..

5) Que diriez-vous de nommer ces choses - pour mon exemple ci-dessus au sujet de FOO/BAR peut-être quelque chose qui se termine par contrôleur serait le C, comme FancyWindowOpeningController, etc? Et pour les modèles - devrais-je les suffixer avec comme GravityBallPhysicsModel etc, ou devrais-je juste nommer ceux que j'aime? Je n'ai pas vu assez de code pour savoir ce qui se passe dans la nature et je veux partir sur la bonne voie dès le début

Merci d'avance de m'avoir mise au courant ou de m'avoir fait savoir que je suis sur la bonne voie. Je sens que je commence à l'obtenir et la plupart de ce que je dis ici est logique, mais la validation de mes devinettes m'aiderait à me sentir confiant ..

Answer 1

Je pense que tous vos exemples confondent les opérations/fonctions individuelles avec l'application globale conception.Donc, la réponse générale à toutes vos questions est que, non, chaque opération ou fonction de l'application ne doit pas utiliser les trois composants MVC. Le véritable objectif de la conception MVC est de rendre chaque composant modulaire et autonome dans toute la mesure du possible. Par conséquent, exiger que chaque opération de chaque composant implique les trois composants MVC irait à l'encontre de l'objectif du modèle de conception en premier lieu.

Les modèles et les vues doivent être conçus de façon à ce qu'ils fonctionnent en principe sans l'autre. Les modèles devraient fonctionner si leurs données sont affichées dans les fenêtres, dans les webviews, les fichiers, imprimés ou en ligne de commande. Les vues doivent pouvoir afficher la version vide d'elles-mêmes. Seuls les contrôleurs doivent connaître les objets de modèle et les objets de vue, mais l'objectif principal des contrôleurs est de lier les deux.

questions: Vous

(1) Si les éléments d'interface utilisateur ont pas besoin de faire référence à quoi que ce soit en dehors de la vue immédiate, la logique de contrôle des éléments d'interface utilisateur appartiennent à la vue. Vous savez qu'une vue est correctement encapsulée lorsque vous pouvez la déplacer vers un autre projet avec un modèle différent et un contrôleur différent et cela fonctionne toujours.

(2) Vous n'avez pas besoin de modèle dans ce cas car vous ne modélisez rien. Un modèle est une représentation de données d'un objet ou d'une action physique. Si les fenêtres et le contrôle n'affichent pas de données représentatives, ils n'ont pas besoin de modèle. Ils sont en train de se dessiner. (3) Vous avez besoin d'un contrôleur pour ne pas avoir à réécrire le modèle ou la vue chaque fois que vous effectuez un changement dans l'autre. Ce n'est pas évident dans les petits projets, mais une fois que vous en avez un avec plusieurs interfaces différentes (interface utilisateur, réseau, opérations de disque, etc.) et de nombreuses façons de représenter dans chaque interface, vous attachez la vue au modèle. (4) Si vous n'avez pas de contrôleur, alors votre modèle doit avoir des références à chaque vue unique. Le système de plume utilise le contrôleur comme objet qui gère les autres objets de la plume. Vous devez avoir un objet hiérarchique et le propriétaire du fichier remplit ce rôle.

(5) Plus le nom est long et descriptif, mieux c'est. Dans six mois, lorsque vous reviendrez faire la maintenance, vous ne vous souviendrez plus de la fenêtre "WindowOpeningController" qui s'ouvre, ni de quoi, le cas échéant, il est spécial. La meilleure façon d'apprécier MVC est de prendre du recul et de réfléchir à des applications vraiment grandes, vraiment complexes et en constante évolution. Ensuite, ajoutez dans la réutilisation des composants dans différentes applications. Ensuite, ajoutez dans le débogage chaque composant. Il devient rapidement clair pourquoi c'est un grand modèle de conception.