autre que les aspects "philosophiques" de celui-ci, est-ce une mauvaise idée d'avoir mon contrôleur aussi mon modèle?
Il semble sauver un temps de programmation. Je n'ai pas besoin de créer une logique entre le contrôleur et le modèle, car c'est la même chose. Et je peux interagir directement avec la vue.
Quel est le point de séparer le m et le c? La modularité est-elle, la possibilité d'échanger un modèle et un contrôleur défini pour un autre - la seule raison de les séparer? Il me semble que "l'échange" Les modules de sortie se produisent beaucoup moins que (par exemple) avoir à mettre à jour le modèle et le contrôleur, car quelque chose dans le modèle change.
Il semble étrange qu'une simple calculatrice, selon le concept MVC, doit avoir à la fois un contrôleur et une vue pour ses paramètres (comme paramètres par défaut ou quelque chose). Je sais que c'est un exemple simple, mais il semble s'appliquer à tous les cas (sauf peut-être des cadres).
7 Réponses :
Si cela fonctionne pour vous, cela fonctionne. Point final. La raison de la séparation des modèles, des vues et des contrôleurs tourne autour de l'idée que la plupart des applications de développement des entreprises sont effectuées par une équipe de développeurs.
Imaginez 10 développeurs essayant de travailler sur votre contrôleur. Mais tout ce qu'ils veulent faire, c'est ajouter quelque chose au modèle. Maintenant, votre contrôleur s'est cassé? Qu'ont-ils fait?
Les modèles sont généralement des composants distincts pouvant être réutilisés entre les contrôleurs. Si vous êtes Je suppose que l'on pourrait dire pourquoi même utiliser la conception MVC si vous envisagez de dévier. Peut-être qu'il y a un modèle plus approprié à suivre pour votre situation. Pouvez-vous nous donner un exemple de quelque chose que vous avez fait où le contrôleur est le modèle? Cela nous aiderait à comprendre ce que vous essayez de faire mieux.
Même pour un éditeur de texte de base, il n'a pas de sens de séparer les M et C. Pourquoi les données internes de l'éditeur ne devraient-elles pas contenir le document actuel?
Même dans un éditeur de texte "simple", vous pouvez vouloir plusieurs fenêtres affichant le même fichier texte ou plusieurs vues de la même fenêtre indiquant différentes parties. C'est difficile si vous mélangez; facile si vous vous séparez.
MVC est un modèle standard qui est bien compris dans la communauté de développement et pour de bonnes raisons. La séparation facilite la lecture des choses, faciles à résoudre, facile à trouver et facile à tester, comme composants individuels, chacun avec son propre domaine de responsabilité.
Devez-vous l'utiliser? bien sûr que non. Mais garder les pièces séparées est généralement considérée comme une bonne idée.
Le contrôleur sait comment relier une vue spécifique à votre modèle. La séparation du modèle et du contrôleur, en dehors de l'amélioration de la documentation et de la maintenabilité, a l'avantage immédiat de permettre à plusieurs vues d'afficher les mêmes informations du modèle sans ajouter de complexité non plus.
qui s'applique non seulement à plusieurs vues dans la même application, mais également aux multiples variations des vues, vous aurez sur plusieurs versions de votre application. Votre modèle est isolé et propre logiquement.
Combinaison de modèle et contrôleur est une fausse économie classique à mon avis. On peut sembler que cela sauve quelques minutes, mais cela coûte de manière significative comme une application se développe et se développe.
La principale raison concerne la réutilisabilité du code. Si vous n'allez jamais écrire un programme dans votre vie professionnelle, alors cela n'a pas d'importance. Si vous envisagez de faire une carrière, les pièces réutilisables sont précieuses. Les classes de modèle, de contrôleur et d'affichage bien conçues sont très faciles à tomber dans d'autres programmes. Je fais tout le temps.
considérer Il y a d'autres moyens de diviser les choses. Certaines langues sous-classent la sous-classe plutôt que de déléguer. Mais dans le cacao, le principal moyen de diviser les programmes est MVC, et cela fonctionne très bien.
La manipulation de la mémoire est beaucoup plus facile dans le MVC. Vous pouvez conserver vos objets de modèle et jeter vos objets de vue (et bon nombre de vos objets de contrôleur) lorsqu'ils vont offcreen.
Il est plus facile de sérialiser des objets de modèle qui ne sont pas emballés avec des contrôleurs et des vues, et il est beaucoup plus facile d'afficher les mêmes données de plusieurs manières. Même dans un éditeur de texte "simple", vous voudrez peut-être pouvoir faire de l'écran divisé ou avoir plusieurs fenêtres indiquant le même document. En MVC c'est très facile.
Si vous n'avez pas besoin de flexibilité maintenant ou à l'avenir, vous n'avez pas besoin de beaucoup d'architecture. Mais la plupart des projets réels ne sont pas si simples. MVC a grandi de l'expérience de Xerox avec l'écriture de grands programmes et les difficultés rencontrées lorsque tout a été jeté ensemble.
edit 2: Je cherchais votre édition précédente: "Il semble étrange qu'une calculatrice simple, selon le concept MVC, doit avoir à la fois un contrôleur et une vue pour ses paramètres (comme défaut paramètres, ou quelque chose). "
C'est exactement la raison du MVC. Il semblerait fou de pouvoir recoder toutes les choses nécessaires à la sauvegarde des paramètres de l'utilisateur spécialement pour une application de calculatrice. Vous voudriez un "Veuillez enregistrer ces paramètres utilisateur" qui était complètement séparé de l'interface utilisateur et que vous pourriez réutiliser. Sur OS X, il s'appelle utablevoller , qui est un contrôleur. Maintenant, imaginez s'il a été conçu exclusivement pour gérer les pistes de musique (le modèle) et vous devez créer une classe de gestion de table complètement différente lorsque vous vouliez gérer autre chose. Éviter ce cauchemar est pourquoi MVC est fortement utilisé dans le cacao.
nsuserdefaults , et la calculatrice L'application stocke sa configuration dans cette voie.
UitailViewController fait partie d'un cadre. Je comprends pourquoi c'est une bonne idée des cadres d'utiliser MVC. Mais pourquoi les projets individuels devraient-ils utiliser MVC?
Pour la même raison traite les cadres. Vous pouvez donc réutiliser le code, et vous pouvez ainsi garder le code concentré sur sa part du problème, ce qui facilite le refactoring. Encore une fois, si vous n'écrivez jamais un autre programme dans votre vie et que vous ne prévoyez pas de maintenir celui-ci pendant très longtemps, puis tout jetant ensemble pourraient bien aller. Mais une collection de codes et de projets réutilisables faciles à refacteur sont des parties importantes de tout outil de boîte à outils de développeur professionnel à long terme.
Mais avec cette logique, la base de code explose. Je devrais avoir une vue pour l'éditeur. Ensuite, je devrais avoir un contrôleur pour l'éditeur. Ensuite, je devrais avoir un contrôle contrôlé pour le modèle (pour vérifier qu'elle est écrite correctement, validée, etc.). Puis coller sur le contrôleur avec le modèle.
Sur Mac, consultez / Developer / Exemples / TextEdit Pour voir comment un éditeur de texte simple est décomposé en MVC. Ceci est le code source réel à l'application textedit fourni avec le système d'exploitation. Je ne pense pas que ce soit un nombre déraisonnable de cours. Je les compterais comme 3 modèles, 7 contrôleurs et 3 vues. Quatre des contrôleurs sont des contrôleurs de l'interface utilisateur et trois contrôleurs de modèle. Notez qu'une grande partie de celle-ci est écrite dans l'objectif C 1.0, raison pour laquelle la plupart des accesseurs sont écrits à la main. Mais c'est un bon exemple.
@Rob basé sur votre dernier commentaire: quelle est la différence entre contrôleur UI VS contrôleur de modèle ?
Un contrôleur de modèle gère des objets de modèle. Par "contrôleur d'interface utilisateur", je veux dire "des choses qui gèrent les objets d'affichage" tout en essayant d'éviter le terme spécifique "contrôleur d'affichage". UIVIEWCONTROLLER est le type le plus courant dans iOS, mais sur Mac, il est un peu courant d'avoir des objets de contrôleur UI qui ne sont pas NsviewController ou NSWindowController . ( nsviewController n'est pas aussi utile une classe que uiviewcontroller .)
MVC est tout sur la gestion (séparation des données, une représentation et une logique commerciale). Donc, c'est comme ça: si vous exécutez une petite entreprise, une gestion de la taille de la MSS serait une vraie traînée. Mais si vous êtes une société géante, n'ayez pas une grande gestion intermédiaire est impossible.
Honnêtement, dans la plupart des missions de mon collège programment, j'ai combiné les modèles et les contrôleurs, car je n'ai pas vu le besoin de la séparation. Mais travailler sur de grands projets? La carence serait assez évidente si vous essayez de ne pas séparer. Faites juste ce que vous vous sentez bien.
Le modèle dépend de la vue ni du contrôleur. Ceci est l'un des principaux avantages de la séparation. Cette séparation permet au modèle d'être construit et testé indépendant de la présentation visuelle.
Je vous suggère de supprimer toutes les tags autres que «MVC», ils ne sont pas pertinents pour cette question.