Je concevons une application Web avec codeigniter (mais je pense que la question s'applique généralement à la MVC modèle dans les applications Web).
Quand je concevie la classe de modèle pour une entité de base de données (disons, a Blogentry Code> Pour illustration), j'ai essentiellement deux choix: p>
L'approche "Classic OOP" serait, de laisser la classe représenter em> l'entité, c'est-à-dire une L'instance de la classe est em> un blogentry. Dans CodeDigniter, cela conduirait à un code comme P> $this->load->model('blogentry');
$the_entry = $this->blogentry->get_entry($id);
3 Réponses :
Tout avant tout ce qui précède, le codeigniter est en classique / traditionnel MVC (non quelles cadres réclamations est MVC), un modèle n'est pas une classe ou un fichier unique, mais plutôt une couche contenant toute la logique commerciale de domaine et généralement ne sont faits que de choses comme Objets de domaine , mapper de données et quelque chose à gérer l'interface entre l'entité appelante et la logique de domaine, afin de garder un tel code hors du contrôleur (en MVC , par exemple). Tereško les noms "Services" , qui est assez bon pour un nom quasi-officiel.
Donc, dans le MVC traditionnel, demande à la couche de modèle COM dans "Services", qui interagissent à son tour avec les objets de domaine et les mappeurs de données.
Évidemment, tout cela a peu de pertinence pour quels CodeIntre et autres cadres appellent "MVC". Dans ce modèle de conception (je vais l'appellerai "CIMVC" pour abréger), un modèle est une classe appelée et manipulée par le contrôleur et interagit directement avec la base de données. Stockage des données dans les variables des membres dans le modèle ne fait pas beaucoup de sens sémantique, mais si vous êtes intéressé par quelque chose de similaire, consultez l'un des plugins / bibliothèques de l'ORM écrites dans CIMVC. (Bien que les solutions ORM ne soient pas meilleures pour se conformer au MVC traditionnel ...)
comme pour les pratiques communes, la plupart des applications CI que j'ai vues renvoient des données de base de données "brutes" à l'automate pour la manipulation; Cela maintient la logique commerciale de domaine dans le modèle. Ma préférence personnelle dans CIMVC est de minimiser / éliminer tout sauf logique commerciale de domaine dans les modèles.
TL; DR - "traditionnel / approprié" MVC dans le codeDIDEDIGRES est essentiellement impossible, alors essayant de forcer votre code CI à se conformer aux paradigmes traditionnels MVC, c'est idiot (et vous conduira probablement à la folie)
En désaccord sur peu de logique commerciale dans le modèle, c'est exactement où la logique commerciale devrait résider (modèles de graisse / contrôleurs skinny). C'est ainsi que la logique BIZ peut être partagée n'importe où dans l'application qui en a besoin.
@MikepurCell Vous avez raison, je n'ai évidemment pas corrigé la réponse que bien ... Le modèle gérera toute la logique commerciale de domaine, mais ce que le point que j'essayais de conduire chez lui était une programmation solide, en particulier le SRP. Je vais mettre à jour la réponse pour être plus claire. EDIT: Alors que je lisais à nouveau ce paragraphe, je ne sais pas Qu'est-ce que Je pensais où j'ai écrit une "logique d'affaires" ... elle contredit complètement mes pensées antérieures: p
Lol, aucun problème, pensé que quelqu'un devait avoir glissé quelque chose dans votre eau.
Bien que je n'ai jamais utilisé CI, je ne vois rien dans la définition de Smalltalk / MVC traditionnelle qui exclut CakePHP et d'autres cadres MVC. Dans Cake, la couche de modèle est principalement composée d'un objet de domaine et d'un mappeur de données. Le fait que dans des cadres Web, la couche de modèle est composée de classes de modèle n'est pas pertinente. C'est toujours le même modèle architectural. En fait, la liste des responsabilités de l'objet de domaine est à peu près une description point à point d'un modèle de gâteau standard.
@ Lèsemajeste, dans CakePHP le modèle " "L'instance d'enregistrement actif (une orèse), qui est directement exposée au contrôleur. Entraînant ainsi une fuite de la logique commerciale de domaine dans les contrôleurs. Il n'y a pas de couche là. De plus, pourriez-vous expliquer, comment vous êtes arrivé à la conclusion, que les cadres PHP implémentent le modèle MVC? Où est la vue?
@teresko: Vous n'êtes pas sûr de ce que vous entendez par "Causer la logique commerciale de domaine pour fuir les contrôleurs". L'enregistrement actif est conçu pour encapsuler la logique du domaine et les données qu'il fonctionne sur - essentiellement un type d'objet de domaine. Vrai, rien n'empêche un développeur de l'écriture de la logique de domaine dans leurs contrôleurs, mais ce n'est pas le gâteau. Une application de gâteau typique aurait des modèles de graisse, des contrôleurs maigres, où le contrôleur ne manipule que indirectement les données en appelant principalement des méthodes de modèle générique. La logique spécifique au domaine comme la validation et le comportement du domaine réside strictement dans les modèles ...
... et comportements de modèle. En ce qui concerne la vue, CakePHP a une classe d'affichage qui est responsable du rendu des modèles de vue et d'encapsuler la logique de présentation (dont certaines dans la classe d'affichage elle-même, d'autres personnes dans les assistants décédées dans l'instance de vue et une petite quantité dans les modèles et éléments). Enfin, le fait que les modèles sont directement exposés aux contrôleurs ne négocient pas le fait qu'il y a une couche de modèle. Par exemple. Une couche d'accès aux données peut être directement exposée au client, mais elle est toujours une "couche". C'est une couche qui résume l'accès des données du client.
@ Lèsemajesté, chaque fois que vous retournez quelque chose au contrôleur, il suffit de décider de l'appel ORM à effectuer ensuite, vous avez une logique de domaine dans le contrôleur.
@ Lèsemajesteté et il n'y a pas de classes de vue. Il y a une seule "vue" classe , qui rend un fichier de modèle. Je pense que vous ne comprenez pas quelle est la "logique de présentation". Mais là encore, vous êtes fanatique de CakePHP qui est enflammé dans un sujet avec CodeIdItre Tag.
La discussion est allé loin au-delà de ce que je demandais, mais merci de toute façon, très intéressant et bon point de départ pour d'autres pensées :). Ce qui m'a aidé était de penser au modèle en tant que couche au lieu d'une classe, donc je vais interpréter le métradant blogmodel en tant qu'interface / façade dans cette couche et laissez-le simplement renvoyer les données. Merci à tous!
Ceci est une réponse générique liée au paradigme MVC, comme je 0 expérience avec CI, mais avoir une expérience forte avec Symfony, Zend, Propel et Doctrine.
je l'ai trouvé, en utilisant la doctrine, cet objet de retour données au sein d'une structure spécifique, il est préférable d'ajouter une méthode qui spécifie ladite structure. Par exemple des objets Doctrine_Record ont une méthode toArray () code> qui me permet de convertir l'objet d'un tableau, donc je ne peux soit accesseurs objet d'utilisation, ou appelez toArray ( code>) et de traiter avec l'objet comme un tableau. p> // Accessing object data through available methods
foreach ($object->categories() as $category) {
var_dump((string) $category);
}
// Accessing object data as an array
$objectAsArray = $object->toArray(true);
foreach ($objectAsArray as $element) {
var_dump($element['Category']);
}
Autant que je sache, il n'existe aucune méthode comme celle-ci dans le modèle de codeigniter, mais vous pouvez spécifier des types de retour à partir d'appels DB avec (par exemple): $ Query-> résultat () vs $ Query-> résultat_array ()
@orourkek: Merci pour l'utilisation spécifique, ma réponse était plus générique que je n'utilise pas CI. Ravi de voir qu'ils permettent la même flexibilité cependant.
La première chose à comprendre est que CodeIdIditer est assez loin des modèles de conception appropriés MVC ou MVC. Il n'y a pas de nom officiel que le modèle de CodeIdItre implémente, mais il est étroitement lié à Ruby sur rails.
Le problème le plus grave découle de la manière dont la couche modèle a été mise en œuvre. Documentation de la traversée Il est conseillé d'utiliser Enregistrement actif modèle, qui introduit par lui-même plusieurs problèmes de conception:
L'autre problème majeur est le manque de vues. Les points de vue doivent être des instances, qui contiennent une logique de présentation. Cela inclut le choix de quels modèles à utiliser pour la représentation des informations, qui a été acquis à partir de couche modèle. Les vues ne sont pas des modèles, ce sont des structures qui utilisent des modèles. em> p> Le meilleur moyen de créer une couche de modèle appropriée au-dessus de CodeCatre serait d'ignorer Services essentiellement reçus des commandes / des messages du contrôleur, qui modifient l'état de la couche modèle et Fournissez une méthode pour extraire des informations à partir de la couche de modèle. Habituellement, l'extraction se produirait dans les cas em> les cas, mais cela n'est pas possible dans le codeigniter. L'extraction d'informations se produirait également dans les "contrôleurs", que la transmettez les données aux modèles. P> code ressemblerait à ceci: p> cI_model code> , car je n'ai aucun avantage dans Extension de cette classe. Créez plutôt quelque chose comme services code>. Ces structures pourraient agir en tant qu'interfaces (pas dans OO Sense) pour une interaction avec la couche de modèle. Chaque Service EM> pourrait traiter plusieurs Objets de domaine et mapper . p> class Library
{
protected $current_document = null;
public function acquire_document( $id )
{
$document = load_class('Document', 'domain_object');
$document->set_id( $id );
$mapper = load_class('Document', 'persistence');
$mapper->fetch( $document );
$this->current_document = $document;
}
public function get_document_information()
{
$document = $this->current_document;
if ( $document === null )
{
return 'empty';
// you either did not acquire the document
// or document was not found
}
return $document->get_details();
}
}
Votre description de MVC ne correspond pas vraiment à la description du MVC de Trygve Reenskaug, ni de la hiérarchie de la classe SmallTalk-80 MVC, dans laquelle il sont Modèles classes / objets que les contrôleurs interagissent directement.
@ Lèsemajesté, oui, je suis l'interprétation de Martin Fowler [1 , 2 ] de modèle de conception MVC. Vous devez également garder à l'esprit que cela se trouve dans le contexte du Web, où quelque chose, même proche du MVC classique, est impossible ou presque impossible.
Jetez un coup d'œil à cette réponse épique comme référence.