De base MVC (PHP) de la Structure

J'ai le texte suivant de flux de données pour un simple formulaire de connexion.

De l'utilisateur du contrôleur d'accès de fichier PHP. Contrôleur comprend model.php et view.php

Utilisateur soumet le formulaire, le contrôleur envoie publier des données sur le modèle des méthodes, et obtient un résultat en retour.

Utilisateur est connecté, et transmis à un point de vue différent (login message de réussite) par le contrôleur.

Actuellement mon point de vue statique en HTML (pas de PHP), voici donc ma question. Quelle est la bonne façon de passer ensuite à l'utilisateur un message de bienvenue, e.g "Bonjour, Craig!"?

Est le point de vue admis PHP extraits de l'e.g

<?php echo $username; ?>

puisque le modèle est chargé avant dans le fichier de contrôleur?

Merci!

Edit: Est-il préférable de permettre à la vue d'accéder à des méthodes de la classe e.g

<?php $user->getUsername(); ?>

plutôt que de simplement les variables?

Sur la base d'autres réponses, j'ai trouvé un article très utile, qui vous pourriez également être intéressé par.

http://www.nathandavison.com/posts/view/7/custom-php-mvc-tutorial-part-5-views

Contenu dynamique doit être transmis à partir de l'action à vue et affiché, il est donc permis d'utiliser des variables php dans les vues.
je pense que le modèle est contenant la classe, si vous utilisez oups, vous pouvez appeler la méthode à chaque fois que vous voulez vous obtiendrez ainsi les données du contrôleur, mais il sera plus compliqué et utiliser plusieurs serveur (car il ont plus de requête )

OriginalL'auteur Craig Wilson | 2012-07-27

  1. 9

    Vous pouvez vraiment mettre quelque chose en vue que vous le souhaitez, mais pour mieux adhérer à la MVC façon de faire les choses que vous devriez limiter PHP dans la vue simple echos ou prints (éventuellement vraiment de petites boucles ainsi, bien que même ceux-ci peuvent être pré-calculées dans le contrôleur/modèle). Puisque c'est la seule façon d'obtenir du contenu dynamique, il serait un peu ridicule de dire qu'ils ne sont pas autorisés.

    L'idée de la vue est de la laisser en plus de HTML look-and-feel, de sorte qu'avant la fin de développeurs ou des gens qui ne connaissent pas le PHP peut facilement être en mesure de travailler avec les fichiers sans se confondre.

    Mise à jour

    Pour en savoir plus sur MVC en général, vous pouvez voir l'un de ceux-ci (il ya une tonne de tutoriels):

    http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/

    http://php-html.net/tutorials/model-view-controller-in-php/

    http://www.tonymarston.net/php-mysql/model-view-controller.html

    Pour voir des exemples concrets de PHP en utilisant MVC, je vous suggère de télécharger certains de la plus prevelant cadres (comme CodeIgniter, Symfony ou Drupal) et à la recherche à travers le code. Essayez de comprendre comment il fonctionne et ensuite recréer les fonctionnalités pour un simple article.

    bien sûr. Il est tout au sujet de la séparation des préoccupations, parce que ni vous ni personne d'autre ne sait ce qui va se passer dans l'avenir (vous risquez de perdre les gens sur votre projet ou de décider qu'il est moins cher de plus quelqu'un qui ne connaît que le HTML). Aussi, l'architecture se prête à l'augmentation de la sécurité par strictement permettre seulement certaines informations à la couche de présentation.
    Comment le contrôleur / modèle de pré-calculer les boucles sans violer SRP de sorte que la vue peut l'utiliser?
    Quoi que vous fassiez, ne pas utiliser de Codeingiter comme ligne directrice si vous voulez apprendre la bonne manière. Vous pouvez regarder la Symfony2 c'est l'un des mieux (moins mal) là-bas.
    -1 pour suggérer une telle horrible des morceaux de code que codeigniter et drupal. Et des liens vers des tutoriels qui dénaturent modèle MVC.
    Aussi, pourquoi l'avez-vous un lien vers la Symfony 1.x site? Crois-moi deviner, vous aviez entendu dire que "symfony est tout à fait ok" de développeurs, mais n'étaient pas au courant de la façon dont différents de 1.x et 2.x versions sont.

    OriginalL'auteur Jeff Lambert

  2. 19

    Voici quelques choses que vous devez considérer:

    • Vous ne pouvez pas faire classique MVC en PHP. Au lieu de cela, nous avons MVC-inspiré modèles
    • Il existe 1:1 relation entre la vue et le contrôleur cas, lorsque mis en œuvre pour le web
    • Modèle MVC n'est pas une classe. C'est une couche qui contient beaucoup de différentes classes
    • Vue n'est pas un idiot modèle, mais d'une instance de classe, qui traite de la logique de présentation

    Vue sur le Web MVC

    Comme indiqué ci-dessus, vues en MVC et MVC motifs d'inspiration sont responsables de la logique de présentation. Qui englobent des choses comme montrant des messages d'erreur et de la pagination. Pour ce faire, chaque point de vue peut gérer plusieurs modèles.

    Vue reçoit des informations de la couche modèle, et agit en conséquence. La manière dont l'information à partir du modèle de la couche termine dans les points de vue est l'une des différences les plus importantes dans MVC-ish motifs:

    • classique MVC modèle

      Structures à partir du modèle de la couche d'envoyer les informations à afficher, lorsque l'état de modèle a été modifié. Cela se fait via modèle observateur.

    • Model2 MVC et HMVC modèles

      Vue dispose d'un accès direct à la couche du modèle et est en mesure de demander des informations. C'est le plus proche de l'original.

    • MVVM et MVP modèles

      Vue reçoit des informations par le biais de contrôleur, qui a à son tour demandé à partir du modèle de la couche. Le plus de différence dans les modèles provient de ce que le faire avec des données avant de les transmettre à la vue.

    Ce que vous semblez avoir maintenant est en fait juste un modèle. Semblable à l'un, qui est décrit dans cet article. Vous vous retrouvez avec une structure, qui n'a pas de place pour contenir la logique de présentation. À long terme, ce sera la cause de la présentation de la logique de poussée dans le contrôleur.

    Alors que "bienvenue" message ?

    Pour afficher le message de bienvenue, votre point de vue demande modèle de couche le nom de l'utilisateur actuel. Si la couche de modèle renvoie une sorte d'état d'erreur, en vue de choisir le message d'erreur du modèle et l'insère dans la mise en page.

    Dans le cas où si le nom de l'utilisateur a été récupéré à partir du modèle de la couche sans problèmes, en vue de choisir le modèle qui contiendra le message d'accueil, définit la valeur dans le modèle et le rend.

    Dans quel ordre les pièces doivent être chargées ?

    L'idée, que le contrôleur doit initialiser le modèle et la vue, vient de très primitive de l'interprétation de la MVC pour le web. Motif de savoir que contrôleur de la page, qui a essayé de greffe MVC directement sur les pages web statiques.

    À mon avis, ce devrait être de l'ordre:

    1. Modèle

      De l'initialisation de la structure, par le biais de laquelle vous aurez affaire à un modèle de couche. Le plus probable serait une sorte de service de l'usine, ce qui vous permettrait de construire des choses comme Authentication service pour les connexions et Library service pour le traitement de documents. Des choses comme ça. J'ai écrit un peu long new'ish commentaire sur le modèle de la couche de la structure plus tôt. Vous trouverez peut-être utile.

    2. Vue

      Vous créez une instance de vue basé sur les informations que vous avez recueillies à partir de mécanisme de routage. Si vous êtes à la mise en œuvre de Model2 ou HMVC, puis votre point de vue nécessitera une instance de Service de l'Usine dans le constructeur.

      Si vous êtes à la mise en œuvre de MVVM ou MVP, puis afficher le constructeur a pas d'exigences particulières.

    3. Contrôleur

      C'est la dernière structure, qui permet de créer, parce que le contrôleur est responsable de l'envoi des commandes à la fois la vue et le modèle de couche, puis modifier, puis modifier l'état des deux. Par conséquent, le contrôleur doit s'attendre à recevoir à la fois la vue et le service de l'usine du constructeur.

    Après les éléments de base de la MVC ont été initialisé, vous pouvez appeler une méthode sur le contrôleur, et le rendu de la vue actuelle.

    Il suffit de garder à l'esprit que c'est très simplifié description.

    +1 pour le bien expliqué et pour dire exactement ce qui est mvc.
    "Par conséquent, le contrôleur doit s'attendre à recevoir à la fois la vue et le service de l'usine du constructeur." Juste pour préciser, tu veux dire que le contrôleur devrait être responsable de l'instanciation (en supposant que la programmation orientée objet), le modèle et la vue, en les passant à la fois les paramètres de la route - droit?
    Je ne suis pas sûr de ce que vous comprenez par "route", mais: N, le contrôleur n'a pas initialiser les points de vue ou le modèle de la couche de structures. La vue est injecté dans le contrôleur de l'initialisation du modèle de la couche d'éléments se fait dans l'usine.
    Je comprends que pour le Modèle MVC 2 la View interagit avec la Couche du Modèle, mais pourquoi est-ce par le biais de la ServiceFactory? N'est-ce pas le but d'un ServiceFactory pour construire certains services tels que AuthenticationService, et ensuite de retour l'objet construit au contrôleur, où il est alors envoked? Pourquoi le View besoin de la ServiceFactory - il ne devrait pas être de construire quelque chose, non? Il a juste besoin de données provenant de certains services..
    oui. Dans l'implémentation la plus simple, il pourrait ressemble à quelque chose comme dans l'exemple de code ici: stackoverflow.com/a/15959396/727208 ... de la pensée dans un monde réel de la situation, il sera un peu plus compliqué. Sur une autre note:, lorsque l'on travaille avec de la POO adhérentes code, vous remarquerez qu'il est préférable d'utiliser des espaces de noms Services\Authentication au lieu de AuthenticationService suffixes. Facilite le chargement automatique.

    OriginalL'auteur tereško