Contrôleur vs Modèle - Besoin d'une explication

Je suis sur le début de mon "Apprendre MVC". Fondamentalement, je n'ai pas de gros problèmes avec la programmation orientée objet toutefois, il y a un aspect technique qui a besoin de clarification. Il semble que ma théorie n'est pas tout à fait assez bon.

Actuellement, je suis en utilisant KohanaPHP framework, version 3.

Exemple de situation:
J'ai un site web, où l'utilisateur peut soumettre un article.

J'ai donc la structure suivante:

classes/
    /controllers/
        article.php
    /models/
        articles.php

So far So good. Je n'ai pas de problèmes avec des modèles qui s'étend Kohana_Model cependant, je ne sais pas si je suis sur la bonne façon de modèles à l'aide de l'ORM.

Essentiellement lors de l'utilisation de modèles d'étendre Kohana_Model je vais mettre toutes les opérations logiques dans le modèle. Dois-je en faire de même pour les modèles à l'aide de l'ORM? Dans de nombreux exemple sur le Net j'ai vu des contrôleurs qui a été d'effectuer des opérations logiques sur les entrées d'utilisateur/données de base de données qui est incorrect à mon avis.

Disons que j'ai besoin d'obtenir quelques lignes à partir de la base de données j'ai donc créer la bonne méthode dans le modèle et le retour de l'objet. Je pense que c'est correct, n'est-ce pas?

Fondamentalement, toutes les opérations sur la saisie de l'utilisateur/de données (sélectionnez dans la db, les insérer dans la db, validation), j'ai mis dans les modèles. C'est la façon dont je le comprends modèle de conception MVC. Les modèles doivent prendre soin de tous les "mécanique" des opérations et le contrôleur n'est qu'un "pont" entre les modèles/points de vue et c'est un "front" du moteur.

Est-ce une bonne approche?

Je sais que cela pourrait être une question stupide, pour les utilisateurs plus avancés, cependant je veux apprendre seulement de bonnes pratiques. Si quelqu'un pouvait fournir quelques éclaircissements, je serai ravi.

Ce n'est pas une question idiote. Le sujet est tout à confusion, car l'original modèle MVC ne correspond pas au traitement dans les applications web bien. Donc, ne pas essayer de trouver la "bonne" approche. Il est souvent plus approprié d'utiliser un PMVC-comme la structure, où le modèle est juste l'ignorer interface de base de données.

OriginalL'auteur M. A. | 2011-01-11

  1. 47

    À court terme, votre modèle effectue toutes les opérations sur les données (entrants, sortants, base de données, les fichiers de données...), et votre vue doit prendre soin de l'affichage des données. Le contrôleur doit appeler le modèle nécessaire des méthodes pour obtenir les données prêtes à être passé à la vue. Le contrôleur ne doit pas effectuer les modifications apportées aux données, mais il faut le tester pour obtenir le nécessaire est fait correctement.

    Espère que j'ai fait ce assez clair, laissez-moi savoir si ce n'est pas évident de choses pour vous.

    C'est exactement la concision de réponse dont j'avais besoin pour mieux comprendre la différence entre les Modèles et les Contrôleurs. Je vous remercie.
    Grâce à cela. Maintenant, je sais quelles méthodes doivent être dans un contrôleur ou d'un modèle.
    Le contrôleur ne doit pas effectuer les modifications apportées aux données, mais il faut le tester pour obtenir le nécessaire est fait correctement. Si je suis à vous entendre correctement... nous devrions effectuer la validation des données sur nos contrôleurs?
    De mon point de vue, la validation des données doit être fait lors du remplissage d'un modèle/contrôleur, si cela échoue, alors le contrôleur devrait prendre les mesures nécessaires en fonction de ce qui échoue. Donc, en d'autres termes, le code de validation se fait à l'intérieur du modèle/de la collection, mais le contrôleur est responsable de la décision sur ce qui se passe à côté et/ou appeler le modèle/contrôleur de la méthode de validation afin de vérifier les données.
    La façon dont je le comprends, le contrôleur est l'intermédiaire entre les données (le Modèle) et le quel utilisateur de visualiser (View).

    OriginalL'auteur Poelinca Dorin

  2. 2

    Je n'ai pas travaillé avec KohanaPHP mais il ressemble à un "rails-inspiré' Cadre.
    Dans les rails monde, il est généralement considéré comme une bonne pratique d'avoir skinny contrôleurs et des modèles de matières grasses.

    certains arrière-plan peut être trouvé dans cet ancien article par jamis buck http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model ou dans celle concernant cakephp http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

    Merci pour la réponse. Je vais sélectionner poelinca réponse comme correcte (votre est correct aussi), mais tu as plus de points 😉
    hehe, pas plus 😉

    OriginalL'auteur roman

  3. 1

    L'idée d'séparant la logique de données est que les données ne contiennent pas de logique, donc, de vos modèles, vous ne devrait vraiment être de la désinfection des données.

    Prenez cet exemple:

    public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id = false)
    {
        if(!$user_id)
        {
             $user_id = get_guest_id();
        }
        //Insert
    }
}

    Semble légitime dans la logique des modèles, mais à partir de maintenant, votre application doit être en mesure d'autoriser les visiteurs à publier des articles, ou de ses lacunes et vous avez besoin de modifier les modèles, qui sont ensuite étage vos autres applications /zones de votre site

    Prenez ce scénario:

    Vous avez 2 sites

    • ComputerArticles.com
    • CookingArticles.com

    Maintenant ces 2 domaines pointent vers le même serveur, mais une application séparée en kohona, de ne pas placer n'importe quel domaine de la logique à l'intérieur de vos modèles, vos pourrez utiliser exactement les exemples de modèles à travers tous les domaines.

    Votre Modèle de Méthodes ressemble à:

    public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id)
    {
        $this->compile("articles",array($title,$text,$user_id))->insert();
    }
}

    Et à l'intérieur de vos contrôleurs, vous devez placer toute votre logique que la logique dépend du domaine.

    Pensez à vos Modèles comme une API, où vous avez plusieurs sites à l'aide de la même API, Mais en vertu d'une logique différente.

    Espère que cette aide.

    OriginalL'auteur RobertPitt

  4. 0

    Ici sont à la base de profane définitions des termes -
    Points de vue: Les écrans présentés pour les utilisateurs
    Contrôleur: Un moteur/cadre qui prend en demande, détermine qui les manipule et les délégués de façon appropriée.
    Modèle: en fait Cela vous dit de quel écran pour afficher après et si l'action est faite sur cet écran. Pensez-y comme une mise en scène graphique. Les bords émergents à partir d'un nœud sont les actions et les nœuds qu'ils se connecter à prochaine des écrans en fonction de ces actions.

    Donc un modèle fondamentalement comprend les actions que l'utilisateur n'sur les écrans et leur action des gestionnaires. Le contrôleur appelle tout simplement dans une action correspondante-gestionnaire pour un utilisateur en particulier en action et l'action de gestionnaire est responsable de faire quelque chose d'intelligent avec la demande entrante.

    Maintenant à votre question. Où est la logique métier va?
    Eh bien, c'est l'action de gestionnaire. Ou il est abstrait, quelque part, les gens aiment à l'appel de la couche de gestion. Mais de toute façon elle est déclenchée à partir de l'action des gestionnaires.

    Donc, techniquement, la logique d'affaires fait partie des actions qui sont eux-mêmes partie du Modèle.
    Cela a un sens si vous pensez à ça: Le contrôleur gère l'interaction de l'utilisateur et présente des vues basées sur le modèle (actions + entreprise).

    ** Les fautes de frappe corrigées.

    OriginalL'auteur d-live