Quelle est la profession de contrôleur MVC?

Je suis en train d'apprendre l'architecture MVC. Mais je ne suis pas en mesure de comprendre pourquoi vous avez besoin d'un contrôleur. Voir le code ci-dessous pour mon modèle et la vue.

model.php se connecte à la base de données et récupère le poste. view.php va juste afficher le poste.

model.php

<?php
  $db = mysql_connect("somehostname", "someuser", constant("somepassword"));
  mysql_select_db("somedatabase", $db);

  $result = mysql_query("SELECT post FROM posts WHERE postid='" . $_POST['id'] . "'");
  $row = mysql_fetch_array($result);

  $post = $row["post"];

  mysql_close($db);
?>

view.php

<?php
  require "model.php";
  echo $post;
?>

- Je configurer mon navigateur emplacement de http://whateverhost/view.php?id=5

Cette charge post avec l'id 5. Je n'ai pas besoin d'un contrôleur de ici. Donc, je suis confus pourquoi avez-vous besoin d'un contrôleur?

Remarque: Veuillez expliquer en référence à l'exemple ci-dessus. Je ne suis pas une programmation à la fois geek et de l'apprentissage des choses comme CakePHP, etc. est bouleversant pour moi.

Edit: Il serait grand si vous pouvez ajouter controller.php le code ci-dessus. Qui pourrait m'aider à comprendre le rôle d'un contrôleur et de la façon dont il communique avec le modèle et les vues.

OriginalL'auteur Cracker | 2010-01-17

  1. 14

    Vous n'avez pas besoin d'un contrôleur parce que votre exemple est trivial.
    Un exemple tiré d'un cas réel scénario:

    Supposons que vous avez une application de CAO. L'application de CAO est organisée comme MVC. Vous avez:

    • un point de vue qui est responsable de l'élaboration du modèle actuel, et de fournir cliquable entités.
    • un modèle, qui permet de conserver les données actuelles pour être représenté
    • un contrôleur, dont le rôle est de recevoir les événements de la vue, et de les convertir en entités afin de modifier le modèle.

    Par exemple, l'utilisateur clique sur un carré et le supprime. Le contrôleur va recevoir l'événement à partir de la vue, crée un objet représentant une commande (via le modèle de Commande), l'ajouter dans une file d'attente pour annuler la capacité et exécute la commande. La commande sera alors modifier le modèle, mais la responsabilité de la traduction de vue sur les événements dans la machinerie complexe qui modifie le modèle est sous la responsabilité du contrôleur.

    Bien sûr, vous pourriez dire, pourquoi n'est-ce pas le point de vue de la création d'objets de Commande alors? eh bien, personne ne vous interdit, mais vous finissez par avoir la présentation de la logique de mêlée avec logique de fonctionnement. Cela va à l'encontre de la bonne conception, bien que pour la plupart des cas triviaux, vous pourriez vivre avec cette conception. Par exemple, si votre application de CAO permet d'afficher la liste des objets à la fois comme une représentation en 3D et une liste d'entités, et vous pouvez supprimer à partir de les deux, vous voyez clairement que les deux points de vue à la fois de mettre en œuvre la même logique pour gérer le modèle de commande (mauvaise conception), ou ils ont juste canal le même message à un contrôleur commun (bon design, l'architecture MVC).

    Hmm... un peu difficile pour mon pas si bon cerveau pour le comprendre! 🙁 J'accepte que mon exemple est trivial, et il n'y a pas de réel besoin de contrôleur. Mais je suppose que si j'ai codé la même chose avec CakePHP, il serait obligatoire pour moi de créer un contrôleur. Pouvez-vous m'aider à ajouter un controller.php à mon code. Son bien, même si ce n'est pas faire quelque chose d'utile. Je veux juste comprendre comment les contrôleurs de communiquer avec des modèles et des vues.
    Je ne sais pas CakePHP, donc je ne peux pas vous aider sur ce point. Mon soupçon est comme suit: diviser le modèle (traitement des données) à partir de la vue (présentation). Lorsque la vue devient trop importante, l'isoler dans un autre objet fichier PHP/tout ce qui n'a rien à voir avec la représentation visuelle.
    Pas de. Je ne parle pas de CakePHP. Je suis en train de parler de l'ajout controller.php pour mon code PHP mentionnés ci-dessus.
    ah, eh bien, vous pouvez, mais votre installation est une sorte de mal pour commencer. vous n'êtes pas à l'aide de classes pour commencer... vous êtes juste tout mettre dans un seul fichier... si vous n'êtes pas divisant responsabilité par le biais d'interfaces bien définies (par exemple, les routines d'appel)

    OriginalL'auteur Stefano Borini

  2. 9

    OMI...

    MVC est un très générique modèle de conception qui n'est pas forcément ce qui est bon et ce qui est mauvais. Il y a un modèle, vue et contrôleur. Les responsabilités de chacune de ces choses dépend de la saveur de la MVC, et la saveur de la MVC vous choisissez devrait dépendre de la complexité de votre projet. Par exemple, si vous avez un domain-driven projet, alors les exemples donnés par d'autres ici ne fonctionnerait pas très bien.

    Donc à sa base:

    Modèle: Un objet qui a des données qui seront affichées dans la vue. Si c'est un DTO ou un modèle de domaine n'est pas réellement définie ici, mais je vais partager mes pensées sur ce en une seconde.

    Vue: C'est ce que voit l'utilisateur et la façon dont l'utilisateur interagit. Tout code ou de la logique ici doivent soutenir directement la vue. En d'autres termes ZÉRO logique d'entreprise, ZÉRO logique d'accès aux données, aucune connaissance de quoi que ce soit au-delà de ce que l'utilisateur de voir physiquement. Soit un formulaire web, une fenêtre du bureau de la forme, ou de l'activité (mobile), etc...

    Contrôleur: Probablement le plus ambigu de cette pièce de puzzle. Une chose est sûre, il sert de médiateur entre la vue et le "modèle" et décide également ce qui se passe à côté ou plutôt, des "contrôles" le flux de. Mais il est important de ne pas prendre cette description trop loin. Ce que cette chose ne dépend vraiment de votre compréhension de la MVC. Donc, je vais partager la façon dont je regarde dans un contexte web; mais, fondamentalement, il suffit de dessiner une ligne entre le contrôle de l'écoulement du service et de l'effectuer réellement le service.

    MVC, pour moi, n'est-ce pas une autre façon de décrire la N-tier, comme certaines personnes pourraient prétendre. Il n'y a pas de couches MVC comme MVC est en fait DANS la couche de présentation. Chaque élément de la MVC vit en fait dans la couche de présentation et le modèle MVC juste dit que vous devez les séparer les préoccupations entre l'obtention de données et l'afficher:

    • Modèle: Ce que l'apparence des données. Vraiment juste une structure que le point de vue va utiliser pour obtenir ses données
    • Vue: afficher
    • Contrôleur: essayer de Comprendre où récupérer les données du modèle, ou encore le modèle lui-même.

    Si vous pouvez accepter que l'instruction, puis il devrait aider à clarifier ce que le modèle est vraiment dans ce contexte. Le modèle n'est PAS un objet d'accès aux données et le modèle n'est PAS un modèle de domaine, car aucune de ces choses devraient être, dans la couche de présentation. Alors que nous laisse avec un ViewModel (MVVM) ou un DTO. Je vais aller avec DTO pour des raisons de simplicité.

    Donc, si nous avons accepté DTO que le type de modèle que nous parlons quand nous disons "modèle" dans MVC, alors où allons-nous obtenir? Si le contrôleur ne doit pas être déconner avec l'accès aux données, alors où? Comment au sujet de votre couche de service? Votre couche de service contient tous les "comment" de votre application. C'est le "Faire des trucs" de la couche. Donc, si votre point de vue veut créer un utilisateur, il va recueillir les données et de les transmettre à l'automate. Le contrôleur décide de service(s) pour accomplir la tâche et l'envoie de la requête avec les données nécessaires. La couche de service répond avec un DTO. Que DTO peut être soit utilisée directement ou ajouté à un autre modèle (s'il y a plusieurs services, par exemple).

    Les points importants sont:

    • Le contrôleur ne sais rien à propos de votre domaine (si vous en avez un), il connait votre disposition les services et la façon de les appeler.
    • Absolument pas affaires logique est effectué par le contrôleur. Par exemple, si vous avez besoin d'envoyer un e-mail de bienvenue dans le cadre de la CreateUser opération, qui ne serait pas initié par le contrôleur puisque c'est techniquement une règle d'entreprise. Il serait géré entre votre service et le domaine des couches.
    • À mon avis, pas d'accès aux données doit être effectuée par votre contrôleur. Qui devrait être délégué à une couche de service. De nombreux tutoriels ont tendance à afficher la barre de contrôle de l'interaction avec les référentiels, qui je pense est bien parce que c'est une abstraction, mais l'accès direct aux données devrait être un absolu non pas de n'importe où dans la couche de présentation.

    De nouveau, et ce, dans un contexte web. Si vous travaillez avec MVC dans une application android, peut-être que vous n'aurez pas une couche de service ou d'un domaine. Peut-être que vous aurez à interagir avec une autre race d'objets. Personnellement, j'ai toujours utiliser le service ou l'application de couches, et ce, pour plusieurs raisons qui peuvent ou peuvent ne pas être considéré comme utile à d'autres.

    Donc dans MVC.Net le régulateur est plus comme une API; la vue et de l'API, différent de la présentation des médiums qui sont destinés à travailler ensemble (le backend contrôleur présente des données, l'interface de contrôleur construit des modèles avec des données et de la médiation avec la vue). Dans Angulaire, le contrôleur est le plus proche de ce dont nous parlons ici. Les couches de couches de couches, il me semble. C'est un peu déroutant pour conceptualiser, mais le concept ne jamais réellement se déplace au-delà de la couche de présentation.

    Mais pour résumer: Le contrôleur "contrôles" les opérations et les données qui entrent et sortent de votre système, et à partir de la vue mais fait pas les affaires. Les détails de ce processus dépend fortement de votre philosophie de conception pour le projet.

    Quelle est la profession de contrôleur MVC?

    Donc ici, dans ce schéma, j'ai regroupé les concepts de montrer MVC au sein de la N-tier typique d'application monolithique. La communication s'exécute de gauche à droite et de ne pas sauter sur n'importe quelle autre couche (voir: l'Oignon de l'Architecture). Dans la couche de présentation, le contrôleur sait à propos du modèle et de la vue, mais la vue et le modèle de savoir à propos de rien pour la plupart. Cependant, dans de nombreuses saveurs de la MVC, y compris ASP.Net et MVVM, la vue peut connaître le modèle de interface ou d'un prototype (mais pas le modèle de l'instance), de sorte qu'il peut se lier à elle.

    Le contrôleur va s'occuper de la manipulation du modèle (ou modèle de vue dans ce contexte), ce qui signifie qu'il peut avoir besoin de savoir à propos de l'objet du domaine et des services de domaine. Vous pouvez éventuellement insérer une couche d'application entre la couche présentation et le nom de domaine si vous voulez un plus réutilisable application (par exemple, votre application peut avoir plusieurs têtes: une API web et une application de bureau et une application mobile, etc.) pour fournir dans les opérations de délimitation et d'isolement. Il est important que la vue n'a pas de connaissances/de la dépendance sur les objets du domaine dans cette architecture -- c'est pourquoi il existe un modèle distinct de la vue. Le point du modèle MVC est de créer un modèle pour la vue. C'est un modèle spécifiquement conçu pour servir la vue, PAS le domaine. C'est ok pour le modèle de vue pour envelopper/adapter le modèle de domaine tant qu'il n'est jamais exposée au public et/ou accidentellement sérialisé.

    Sur une note de côté, la "couche de présentation" dans une API web, à mon avis, est la sérialisé contrat (par exemple, JSON ou XML). Donc la traiter en conséquence.

    Je me demandais. Pourriez-vous nous faire un dessin et de le télécharger à cette réponse? Je pense que cette réponse a une réelle valeur.
    ajouté 🙂

    OriginalL'auteur Sinaesthetic

  3. 2

    Je pense qu'il pourrait y avoir une utilisation d'un contrôleur dans ce cas, et de mauvais montrer le code.

    MODÈLE:

    <?php
  $db = mysql_connect("somehostname", "someuser", constant("somepassword"));
  mysql_select_db("somedatabase", $db);

  $result = mysql_query("SELECT post FROM posts WHERE postid='" . $_POST['id'] . "'");
  $row = mysql_fetch_array($result);

  $post = $row["post"];

  mysql_close($db);

function getPost() {
    return $post;
}
?>

    VUE:

    <html>
<head></head>
<body>
    <input type="submit" onClick="postToScreen();" value="Post">
    <p id="post"></p>
</body>
</html>

    CONTRÔLEUR:

    <?php
    $controllerPost = getPost();
?>

<script type="text/javascript">
function postToScreen() {
    document.getElementById("post").innerHTML="<?php echo $controllerPost; ?>";
}
</script>

    mon javascript est rouillée. je crois que j'ai que le code de droit mais id double le vérifier avant de le mettre dans quoi que ce soit. le contrôleur contrôle que le point de vue ressemble, et dans certaines circonstances, quelles sont les données que le modèle contient.

    ce n'est pas la seule façon de le faire, mais en suivant ce modèle définit le logiciel pour une bonne évolutivité. il y a également la possibilité de combiner le contrôleur et la vue d'en faire un objet appelé "View Controller", qui est un choix populaire en Objective-C/le développement d'applications. le point de vue ne devrait pas contenir n'importe quoi, sauf le nu les éléments qui y sont affichés. essentiellement, toutes les données doivent être contenues dans le modèle et sont définies par le contrôleur.

    OriginalL'auteur Katushai

  4. 1

    model.php est dans ce cas, vous contrôleur.

    Le rôle de modèle, vue et contrôleur ne sont pas faciles à distinguer si vous n'avez pas un bon framework MVC (PHP n'est pas une bonne).

    Le Modèle de votre structure de données qui est effectué de façon continue dans une DB. En termes de code, s'il est principalement composé d'une structure de données en tant que classe.

    La Vue affiche les données. Principalement html avec quelques balises de script.

    Le Contrôleur contrôle ce qui se passe. Par exemple, un utilisateur modifie un post. Les données sont reçues par le contrôleur, peut-être modifié un peu (ajouté horodatage, l'ip de l'utilisateur) et envoyées pour le modèle en vue de la stocker. Le contrôleur décide alors de qui la vue à afficher à côté et quelle de données pour aller chercher de la nouvelle vue.

    Juste un petit exemple.

    OriginalL'auteur rdmueller

  5. 0

    À mon humble avis MVC le contrôleur a deux buts principaux:

    1. La testabilité de l'interface graphique de la logique ou quoi que ce soit de l'interface graphique des déclencheurs. Dans la plupart des cas, vous pouvez écrire des tests unitaires pour le contrôleur relativement facile, il est beaucoup plus difficile pour les Interfaces graphiques comme PHP ou Windows Forms par exemple. L'ancien repose sur un navigateur, le futur dépend de Messages de Windows, à la fois ne pas faire de votre vie plus facile quand vous écrire des tests unitaires. C'est presque le même avec une autre couche de présentation de la technologie.
    2. La interchangability de la couche de présentation ou (dans certains cas) le contrôleur. Il existe des scénarios où vous pouvez utiliser le même contrôleur dans deux des Interfaces utilisateur graphiques (un "léger" pour un cas particulier et un "riche" pour une autre affaire) ou l'inverse (pas si souvent que ça).

    Dans un scénario avec beaucoup plus de fonctionnalités que dans votre exemple, vous verrez les avantages. Mais vous devez vous décider pour ou contre MVC et utiliser la même approche dans chaque forme de la demande, ne pas mélanger. Je préfère MVC, vous n'avez presque toujours besoin d'un contrôleur logique.

    Merci!! Pouvez-vous m'aider à ajouter controller.php à mon code. Qui pourrait m'aider à comprendre le rôle d'un contrôleur et de la façon dont il communique avec le modèle et les vues.
    Son dur pour votre lecture seule de l'échantillon. Par exemple comme ça: modèle: contient des données (dans votre cas: postes) vue: représente les données, l'affichage normal pour les utilisateurs anonymes, vue avancée pour les admins ou quelque chose comme ça. Un exemple pourrait être d'analyser un poste de manière asynchrone quand il a été créé pour les "gros mots", s'ils sont considérés positifs, un rédacteur technique a pour vérifier le post manuellement. Ainsi, après la création du poste votre vue des appels: myController.CheckAsynchronously(PostEntry postEntry); // c'est peut-être pas de syntaxe php 😉

    OriginalL'auteur Carsten

  6. 0

    Je vais essayer seulement de répondre à la question dans le titre. Alors, quel est le rôle d'un contrôleur MVC?

    Il est travail est d'être un modèle de format pour afficher le format de traducteur afin de ne pas avoir d'INTERFACE utilisateur-modèle et d'une INTERFACE utilisateur pilotée par structure de base de données.

    L'idée est de développer la logique métier pilotée structure de base de données, puis de l'indépendance de l'INTERFACE utilisateur. Maintenant, quand nous ajouter ou de déplacer une partie de l'INTERFACE utilisateur de contrôle de notre modèle et de la structure de base de données ne devrait pas changer.

    OriginalL'auteur Paul