Nathan MVC

Bonjour à nouveau !!!!

J'ai adopté le principe de Nathan MVC du URL suivant comme base:http://www.nathandavison.com/article/8/custom-php-mvc-tutorial-part-4-models

Il n'intègre pas la base de donnée PDO avec des requêtes et je souhaiterais avoir de l'aide pour y arriver. Ce message va avec mon précédent.

Je ne comprends pas totalement les instructions de l'auteur à propos des "tips" qu'il indique. A part, cela, j'arrive tout de même à comprendre quelques principe de base.

Bien à vous, Dan.

Salut,
l'exemple cité par Nathan Davison n'est de mon point de vue pas excellent. Il cite entre autres choses « Models are basically just data setters and getters » : c'est très réducteur et pas tout à fait juste.

Les principes fondamentaux d'une structure MVC doivent être parfaitement assimilés : on sépare les différentes couches, traitement de la requête de l'utilisateur (contrôleur), accès aux données et traitement de ces données (Modèle), manière de les présenter vers une sortie,écran, document bureautique ou autre (Vue). Il n'existe par ailleur aucun lien direct entre modèle et vue qui peuvent être modifiés indépendemment sans affecter les autre, c'est à dire par exemple que pour un même modèle, on pourra utiliser différentes vue sans que ça affecte le modèle de quelque manière que ce soit.
Le contrôleur va, selon la requête de l'utilisateur, appeler tel ou tel modèle pour collecter et traiter des données puis sélectionner telle(s) ou telle(s) vue(s) selon les paramètres reçus pour construire ce qui doit être retourné à l'utilisateur, que ce soit sous la forme d'une page HTML, un document PDF ou autre chose.

Pour la partie Modèle, il s'agit de traitement de données : donc on aura d'abord la collecte de ces données. Ça peut être une série de données à récupérer dans une base de données, mais pas obligatoirement, ça pourrait aussi bien être une collection de données envoyées via un formulaire par l'utilisateur ou encore des données issues d'un document texte stocké quelque part. Ensuite, c'est le traitement de ces données, on peut avoir à en valider le contenu (données de formulaire) ou bien les transformer d'une manière ou d'une autre selon ce qui est attendu par le contrôleur, ou encore on peut avoir à enregistrer ces données vers une base de données ou un autre système de stockage.

Dans le cas d'échanges avec une base de données, on fera le plus souvent appel à un objet qui contiendra la connexion avec le SGBD, lequel objet dispose des méthodes CRUD (évoquées dans la réponse à ton précédent message), mais le point important est que ton modèle est (et doit rester) indépendant du contôleur. C'est le contrôleur qui passera au modèle l'objet nécessaire aux opérations que le modèle doit effectuer. Le contrôleur pourra ainsi faire appel à une librairie gérant la connexion à un serveur de base de données, créer une instance de connexion puis appeler le modèle aproprié en lui passant en paramètre l'objet connexion. Ça peut très bien être un système utilisant PDO, et dans ce cas, le contrôleur passera à ce dernier les paramètres de connexion. L'idée générale est surtout que dans ton MVC, le modèle ne connait pas la base de données elle-même ni même la manière de s'y connecter, il attend (et reçoit) un objet disposant des méthodes pouvant récupérer des données (SELECT) les créer (INSERT), les modifier (UPDATE) ou les supprimer (DELETE). Ce que ton Modèle connait en revanche, c'est la manière dont doivent être structurées ces données, donc les noms des tables et pour chaque tables les noms des colonnes, avec le type de données attendues pour chacune d'elle et quelques autres informations propres à chaque colonne.

L'idée de PDO, c'est de limiter la quantité de code. PDO n'est pas une base de données, c'est ce qu'on nomme une Couche d'abstraction, une sorte d'intermédiaire entre ton système de traitement de données et un serveur de bases de données quel qu'il soit. Si aujourd'hui tu utilises une Base MySQL et que pour une raison quelconque tu passes dans deux mois à un serveur Oracle ou PostGreSQL, tu n'auras en principe rien d'autre à modifier que les paramètres de connexion à ton objet PDO, le reste ne changeant pas dans la mesure ou la structure des données dans le SGBD ne change pas non plus. Donc au lieu d'écrire un package pour chaque sorte de SGBD, on en crée un seul s'appuyant sur PDO.

Voilà, je ne suis pas certain que ça réponde bien à ta question, précise au besoin les points qui te semblent encore flous.

Bonjour.
L'idée est : je crée quelque chose (appelle le comme tu veux:objet,truc,bidule) dont la profession est de communiquer avec une bdd.
Il agit grâce aux méthodes définies dans la classe PDO.
Un exemple.
<?php $truc->query($requete);?>
Tu vois,je "lance" mon truc/objet vers la base et lui crie:va chercher!
Raisonner objet ça doit être:keep it Simple!.Le + possible.Sinon,c'est de l’esbroufe intellect pour épater la classe.
Tiens,en parlant d'esbroufe:le terme objet est faux,c'est une adresse(=pointeur en langage c).On doit dire référence d'objet.

Pour commencer, merci à vous deux pour les éclaircissements. C'est bien apprécié. J'ai de quoi pour mieux me baser.

1. J'écris pour montrer si j'ai bien compris.

   «mais le point imoprtant est que ton modèle est (et doit rester) indépendant du modèle.»

2. Le modèle doit resté indépendant du modèle?

   «on sépare les différentes couches, traitement de la requête de l'utilisateur (contrôleur), accès aux données et traitement de ces données (Modèle), manière de les présenter vers une sortie,écran, document bureautique ou autre (Vue)»

Le modèle va chercher la connexion à la

• Va chercher la connexion: include './model/connexion.php';

• Fait la requête de données: $stmt = $this->_conn->prepare('SELECT * FROM artistes WHERE id = :id');

Le contrôleur va traiter ces données soit pour validation:

• Traite le résultat de la requête:

  $artiste_id  = (empty($_GET['artiste']))?'1':(int)$_GET['artiste'];
  

• Prépare le résultat pour la vue: $AfficherArtistes = $oArtiste->afficher($artiste_id);

• La vue affiche les résultat obtenu préparée par le contrôleur : foreach($AfficherArtistes as $a_artiste).....

«C'est le contrôleur qui passera au modèle l'objet nécessaire aux opérations que le modèle doit effectuer»

Ceci:

$oArtiste = new Artiste($cxn);
$ListerArtistes = $oArtiste->lister();

Je ne pense pas que ça veut dire cela.
Le contrôleur passe au modèle l'objet que doit effectuer le modèle.
C'est peut-être là que ça chope pour moi.

C'est dans le modèle:

public function lister(){
    $stmt = $this->_conn->prepare('SELECT * FROM artistes');
    $stmt->execute();  
    return $stmt->fetchAll(PDO::FETCH_OBJ);
}

Avec le modèle, je fais l'objet:

• objet 1: $oArtiste = new Artiste($cxn);
• objet 2: $ListerArtistes = $oArtiste->lister();

Donc, ce n'est pas cela que je passe au contrôleur. Ici je ne sais plus ???

Quand je parle d'exemple, c'est ce que je veux dire. Mais, j'en suis rendu là.
Il me reste le reste du message de Cyrano et l'autre message à raisonner.

Salut,
pour le modèle doit rester indépendant du modèle, autant pour moi, j'ai édité et corrigé mon message, il fallait lire indépendant du contrôleur

La distinction des différents objets semble encore floue. Tu indiques ainsi :

• objet 1: $oArtiste = new Artiste($cxn);
• objet 2: $ListerArtistes = $oArtiste->lister();

En réalité ce n'est pas ça : là, c'est le même objet, d'abord lors de sa création (new) et ensuite dans l'utilisation d'une de ses méthodes. Il y a pourtant bien deux objets : le premier est ici $oArtiste, le second est $cnx.

Le déroulement sera alors le suivant : un internaute demande la page http://tonsite.com/artistes/ : le contrôleur frontal intercepte cette requête HTTP et va en déterminer les paramètres : le premier paramètre est « artistes » et il n'y en a pas d'autres. Le contrôleur frontal va alors déterminer quel sous-contrôleur peut traiter cette requête et lui transmettre cette requête. Ton contrôleur artisteCtrl va alors déterminer quelles actions doivent être exécutées en fonction des autres paramètres s'il y en a, et une action par défaut s'il n'y en a aucun. L'exemple ici n'a aucun paramètre, on est donc dans le cas par défaut et tu définis que dans ce cas, on affiche la liste des artistes. Ce contrôleur a donc besoin du modèle artistes et de sa méthode lister(), mais pour ce faire, le modèle a besoin d'un objet lui permettant d'envoyer une requête SQL pour procéder à la collecte des données appropriées.

Ton conôleur artisteCtrl va donc créer deux objets : un objet de connexion et une instance du modèle;

// Création d'un objet de connexion
$oCnx     = new taClassePdo();
// Initialisation du modèle artiste
$oArtiste = new mdlArtiste($oCnx);
// Récupération de la liste des artistes
$aListeArtistes = $oArtiste->lister();

Ton modèle reçoit donc un objet de connexion permettant d'effectuer des requêtes. Sa méthode lister() va donc pouvoir exécuter une requête, ce que tu as indiqué dans ta réponse :

public function lister(){
    $stmt = $this->_conn->prepare('SELECT * FROM artistes');
    $stmt->execute();  
    return $stmt->fetchAll(PDO::FETCH_OBJ);
}

À partir de là, le contrôleur peut s'occuper maintenant du retour : il faut définir la Vue qui va bien en lui affectant les données en questions. Il y aura donc dans cette vue la construction dynamique du code HTML (ou autre) qui pourra être retourné au contrôleur, lequel pourra alors, une fois tout ça terminé, envoyer le résultat vers la sortie, éventuellement via une classe de vues via une méthode afficher() par exemple.

Salut

Excuse, j'oubli à l'occasion mes salutations qui initie le bon contact et l'échanges. :-)

J'ai vu que j'ai fait une erreur avec l'histoire des deux objets: J'ai pas réfléchi.

$oArtiste = new Artiste($cxn);
$ListerArtistes = $oArtiste->lister();

OArtiste est l'objet
$oArtiste->lister(); est l'appel de la méthode lister de l'objet OArtiste ramasser dans une variable sous $ListerArtistes pour être utilisé en foreach.

$cyn est un paramètre dû au __constructeur de la class Artiste. Et l'objet de ceci du fichier connexion.php :

$cxn = new PDO($dnsh, $user, $pass);

Ce n'est pas évident sur le coup, ça demande une certaine réflexion quand on lit tout cela.

Pour le reste, je vais étudier pour comprendre.

Je crois que tu as saisi l'essentiel.

Commence avec des choses telles que tu les comprends. Partant de là, tu devras dans un premier temps le faire fonctionner, et ensuite, tu pourras sans doute améliorer en déportant certaines parties dans d'autres fichiers/classes et en factorisant. Si tu as utilisé du copier/coller entre divers fichiers par exemple, il sera temps de te dire qu'il faut simplifier en mettant ce code ailleurs et en faisant une inclusion là où tu en as besoin, et de cette manière, tu n'auras qu'un seul endroit à maintenir, et si tu y corriges un bogue, tu n'auras qu'un seul correctif à effectuer pour mettre à jour toute l'application sans risque d'oubli d'une copie quelque part.

Il ne faut pas non plus trop se prendre la tête avec des concepts trop abstraits et/ou théoriques : le but du jeu reste quand même d'écrire moins de code et de rendre la maintenance la plus facile et efficace que possible, le reste, c'est de la littérature.