Discussion :

[T0xF0x]

Bonjour à tous,

J'ai enfin reussi a commencer mon appli MVC et j'ai fait par exemple un module qui liste une bd donc j'ai 3 fichiers : listmodel, listview, listcontroller

Il se trouve que cela marche niquel listcontroller herite de listview et affiche !

En revanche c'est bon pour un module qui liste ! Maintenant si je veux une appli qui fasse plusieurs modules avec un seul model, un seul controller et un seul viewer, comment je peux faire ?

Car pour chaque module je ne vais pas refaire un viewer un controller et un model... Comment je pourrais centraliser svp ?

Merci d'avance à tous

[goodpz]

listcontroller herite de listview et affiche !

Ton MVC est peu orthodoxe alors !

Car pour chaque module je ne vais pas refaire un viewer un controller et un model... Comment je pourrais centraliser svp ?

Généralement, un 'module' est construit soit en héritant, soit en composant à partir de controllers et viewers génériques (ou abstraits). C'est un peu la même choses pour les models, bien que ceux-ci peuvent être très spécifiques par module et donc n'avoir pas d'équivalent.

[T0xF0x]

Comment puis-je faire alors pour construire mon MVC? CONCRETEMENT svp ?

J'aimerais ce qu'on ne trouve pas sur le net : un exemple concret de la construction d'un MVC...

Merci.

[goodpz]

Il y a plusieurs sortes de MVC. En fait, pratiquement autant de MVC qu'il y a de frameworks MVC. Pour les applis web, on retrouve généralement l'un ou l'autre de ces constituants, les plus utilisés en premier (à mon avis) :

C:
- Front Controller + Action Controller
- Page Controller
- Apache + auto_prepend + directory

V:
- Push View (passive)
- Pull View (active)

M:
- Table Data Gateway...
- Active Records
- ORM

Ce qui est en vogue actuellement (Ruby On Rails, Zend Framework) c'est un Front Controller qui reçoit seul la requête et instancie l'Action Controller adéquat. Ensuite ce dernier se charge de manipuler les models pour effectuer les opérations métier et finalement une instance de View est créée pour présenter les données.

La convention veut que les urls soient grosso-modo de la forme:
site.com/controller/action/parameters ou
site.com/module/controller/action/parameters
Le boulot du Front Controller c'est, à partir d'une telle requête, d'appeler la méthode Controller::action();

Exemple:
site.com/article/view/42
==> ArticleCtrl::view(42);

J'aimerais ce qu'on ne trouve pas sur le net : un exemple concret de la construction d'un MVC...

Ca se trouve sur le net. Sur les sites de la plupart des MVC connus (plusieurs threads en font la liste), il y a souvent des informations utiles et surtout le source code. C'est toujours intéressant de parcourir les sources et celles des applications de démonstration.

Ca peut ressembler à ça (très grossier):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class ArticleCtrl extends BaseCtrl {
  public function view($params) {
    $article = Article::find($params['id']); // ZActiveRecord ; )
    $view = new MyView('template.ext');
    $view->assign($article);
    $view->render(); 
  }
  public function list($params) {
    //...
  }
}
 
class Article extends ActiveRecord {
  const table = 'article';
  //...
}
 
class MyView extends BaseView {
  public function render() {
    //...
    parent::render();
  }
}

Dans un tel framework (utopique avec de tels Active Records pour php actuellement), ton premier soucis ça serait de créer BaseCtrl, BaseView, ActiveRecord et un FrontCtrl (non présent dans l'exemple). Le tout suffisamment souple, générique, flexible, extensible pour que développer une application ne soit pas un casse tête ni la fête du refactoring. Ce n'est pas quelque chose d'aisé. Loin de là. Certains font un squelette d'architecture par semaine sans trouver les bon compromis..

Aussi, il y a un membre qui s'appelle sahid ici et qui a posté des articles sympathiques sur son blog: http://sahid.funraill.org
Ca pourra sûrement t'intéresser

[T0xF0x]

Tout d'abord, merci d'avoir pris le temps...

Ensuite le blog de sahid est totu simplement une mine d'or il ne faut surtout pas qu'il l'abandonne ! Egalement je n'arrive pas trop à cerner l'utilité de la classe Article et ActiveRecord... Ca represente le model ? Dequel façon ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class Article extends ActiveRecord {
  const table = 'article';
  //...
}

Merci encore.

[goodpz]

Un Active Record est un design pattern proposé par Martin Fowler (plus d'info sur le net). Ca permet de manipuler des rows de tables de db à l'aide d'objets 'actifs': ils sont au courant des éventuelles relations qui les lient entre eux (foreign keys, one-to-many, many-to-many etc). Les modifications sur ces objets sont répercutées directement dans les tables. C'est plutôt très élégant à défaut d'être très efficace en terme de ressource et performance.

Mon précédent post était en fait un clin d'oeil car une implémentation 'simple' et dynamique d'un tel pattern est quasi mission impossible en php. Techniquement, la raison c'est l'impossibilité de faire du late binding de membres statics. Tout ceci resterait relativement confidentiel si Zend (la société derrière php) n'avait pas laissé entendre que leur framework implémenterait des Active Records tels que je l'ai mis en exemple dans mon précédent code. Plusieurs blogs ont parlé de cet événement, le plus célèbre d'entre eux est probablement: http://blog.joshuaeichorn.com/archiv...ord-cant-work/

Et donc oui, les Active Records serait le model dans l'exemple que j'ai posté.

[zyongh]

Je commence juste (depuis aujourd'hui) à étudier les motifs de conception. Donc peut-être je vais poster une belle connerie Enfin je tente quand-même.

Dans ton exemple goodpz, je ne vois pas la classe HttpRequest:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
class HttpRequest {
    private $_request = array();
 
    public function __construct(){
        $this->_request = array_merge($_GET, $_POST);
    }
 
    public function getParam($param){
        return $this->_request[$param];
    }
}

[goodpz]

Dans ton exemple goodpz, je ne vois pas la classe HttpRequest

Mon exemple n'était qu'une description grossière et 'complètement incomplète' d'une façon d'implémenter un MVC.

Cette classe HttpRequest, c'est celle du blog de sahid ? On peut implémenter des MVC sans utiliser de classe telle que HttpRequest, mais c'est vrai que c'est très fréquent.

[zyongh]

Cette classe HttpRequest, c'est celle du blog de sahid ?

En fait, j'ai lu tellement de trucs aujourd'hui entre le blog de Sahid, un ancien numéro de PHP Solutions (magazine) et des tas de tutos francophones et anglophones que je peux dire que c'est la classe que j'ai le plus vue depuis que j'étudie les motifs de conceptions (c'est à dire depuis environ 24h).