Discussion :

[alejandro]

Bonjour,

Je souhaiterais mettre en oeuvre ma propre implémentation du motif de conception MVC lors du déploiement d'une application web professionnelle. Je sais déjà qu'il existe de nombreux frameworks éprouvés sur la toile et je suis d'ailleurs un grand fan de codeigniter que je trouve très intuitif.

Tous les frameworks disponibles sur internet ont l'énorme avantage de pouvoir fonctionner dans des environnements divers en effectuant beaucoup de vérifications pour voir si telle ou telle fonctionnalité est supportée par le serveur sur lequel ils sont exécutés. Or, c'est un effet à double tranchant : Cette nécessité de compatibilité fait qu'ils requièrent un surplus de calculs dont j'ai besoin de m'affranchir.

Je souhaiterais donc mettre en oeuvre un simple modèle de conception MVC destiné à être utilisé sur mes serveurs et n'ayant pas à se préoccuper de l'environnement dans lequel ils seront exécutés.

Ma question est donc la suivante : Quelle méthodologie utiliseriez vous pour implémenter un modèle MVC ? Quels patrons utiliseriez-vous pour créer votre contrôleur frontal, vos contrôleurs, vos modèles et vos vues ? Qu'est-ce qui se pratique couramment ?

Merci d'avance pour vos points de vue !

[sharrascript]

Salut alejandro,

Je suis tombé sur le même objectif que toi, il y a de cela quelques mois, c'est pour cette raison que je me suis confectionné un petit framework perso sous le model MVC qui s'approche le plus prêt possible de ma logique. Le framework fonctionne, mais est encore à l'état d'embryon. Chaque nouveau cas me permet de le remettre en cause et de le remodeler.

Je suis parti de ma logique personnelle et bien entendu de ce qui se fait (ZF, Jelix, Copix, surtout ceux là), puis j'ai développé le tout autour d'un projet gabarit, ce qui m'a permis de voir et de tester.

Je n'ai pas de réel conseil à donner sachant que mon projet n'est peut être pas une référence, mais le résultat est concluant, j'ai un framework PHP MVC que je connais sur le bout des doigts et qui est adapté à l'environnement que j'utilise et maitrise.

Tout ce que je peux te dire, c'est qu'il y a du boulot, mais que le résultat est intéressant et peut devenir très productif.

Bonne journée ++

[batataw]

Je souhaiterais donc mettre en oeuvre un simple modèle de conception MVC destiné à être utilisé sur mes serveurs et n'ayant pas à se préoccuper de l'environnement dans lequel ils seront exécutés.

Peux-tu etre plus explicite car l'environnement ne peut être ignoré.
Il faut avoir une feuille de route pour pouvoir décider de l'implémentation.

Si c'est juste le MVC que tu veux et pas tous les avantages que peux t'apporter un Framework. Tu peux créer 3 dossiers:
/models
- DB.class.php (Abstrait l'accés a la base)
- Article.class.php
- ...
/views
/article
- list.php
- edit.php
/controllers
controller.php (Class fournissant les prérequis pour les controleurs)
article.php

ton index.php peut prendre en paramètre le controleur + action a effectuer
index.php?c=article&a=list

Si j'étais toi j'opterais plutôt pour un Framework léger qui serait compatible avec tes serveurs.

[alejandro]

Merci pour vos réponses, mon environnement est structuré comme suit : mes serveurs peuvent accueillir jusqu'à une centaine de domaines chacun. Chaque domaine contient pour l'instant deux fichiers qui sont un .htaccess et un fichier index.php.

Mon .htaccess est plutôt simple, il redirige toutes les requêtes vers index.php sauf celles qui concernent les fichiers à télécharger tels que les images, les fichiers pdf, les animations flash etc.

Code :

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

1
2
3
RewriteEngine on
RewriteBase /
RewriteRule !\.(js|ico|txt|gif|jpg|png|css|swf)$ index.php

Ensuite j'ai deux dossiers supplémentaires qui ne sont pas localisés dans les domaines, il s'agit du dossier application et du dossier framework. Le dossier framework contient mon framework et mon dossier application ... mon application

Lorsque je met à jour mon dossier application, tous mes domaines sont mis à jour en même temps, et c'est là mon but premier, car effectuer des mises à jour hebdomadaires sur des centaines de domaines ... je vous passe la suite.

Ensuite mon framework possède un autoloader (fonction PHP5) qui transforme une requête de classe de type Default_Bootstrap en Default/Bootstrap.php et qui va donc inclure ma classe automatiquement.

Mon dossier framework contient principalement des patrons de conception sous forme de classes abstraites et d'interfaces. Il contient également un lot d'outils divers dans un dossier par défaut.

Mon dossier application contient un fichier de configuration pour mon application et trois dossiers pour l'instant : Model, View, Controller.

Je pensais utiliser un patron de conception de type "strategy" pour mes contrôleurs par exemple et un modèle "composite" pour mes vues afin de pouvoir moduler chaque partie de l'interface utilisateur sous forme d'options (je souhaite activer telle option sur tel domaine - par ex. une carte interactive - mais pas sur tel autre).

C'est surtout sur cela que porte ma question, il existe plein de façon d'implémenter MVC et je voulais avoir votre vision d'une implémentation MVC, quels patrons de conception utilisez-vous pour vos vues, vos contrôleurs, vos modèles, votre contrôleur frontal ... ?

[batataw]

C'est un très bon reflex que d'utiliser les Design Pattern pour concevoir ton appli cependant fait attention de ne pas trop compliquer la conception. Autant pour un site web, je suis à fond pour une architecture poussée. Mais là tu risques de te prendre les pieds dans le tapis avec de nombreuses exceptions à gérer.

Pour le controlleur une classe abstraite avec tes méthodes de base genre
preExecute, postExecute

Pour ta base de données, tu pourrais utiliser soit un ORM existant.
- Doctrine
- Propel
- ...
Ou bien utiliser le pattern Active Record

Pour les vues j'irai au plus simple, un truc à la Smarty devrait faire l'affaire
(en plus light).

[alejandro]

Merci pour vos réponses, je pense avoir trouvé un modèle de conception intéressant dans toutes les docs que j'ai lu et je voulais avoir votre avis sur un contrôleur frontal comme celui-ci :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
if( ! class_exists( 'Front_Controller' ) )
{
    final class Front_Controller
    {
        private static $o_Instance = NULL;
        private $h_Filters = array();
        private $o_Strategy = NULL;
 
        private function __construct()
        {
            $this->RegisterFilter( new Front_Controller_Output );
        }
 
        private function RegisterFilter( & $o_Filter )
        {
            $this->h_Filters[] = & $o_Filter;
        }
 
        public static function GetInstance()
        {
            if( ! self::$o_Instance instanceof self )
                self::$o_Instance = new self;
 
            return self::$o_Instance;
        }
 
        public function Execute()
        {
            foreach( $this->h_Filters as $o_Filter )
            {
                $o_Filter->PreProcess();
            }
 
            // $this->o_Strategy->Execute() :
            echo "bonjour";
 
            foreach( array_reverse( $this->h_Filters ) as $o_Filter )
            {
                $o_Filter->PostProcess();
            }
        }
    }
}

Il fonctionne avec les patrons de conception Intercepting Filters, Singleton et Strategy. Je commence par rajouter mon interface pour les filtres :

Code :

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

1
2
3
4
5
6
7
8
if( ! interface_exists( 'Front_Controller_Filter' ) )
{
    interface Front_Controller_Filter
    {
        public function PreProcess();
        public function PostProcess();
    }
}

Puis je crée par exemple un filtre Front_Controller_Output qui va être capable d'agir sur ma sortie (dans l'exemple je met ma sortie en italique ) :

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
if( ! class_exists( 'Front_Controller_Output' ) )
{
    class Front_Controller_Output
    implements Front_Controller_Filter
    {
        public function PreProcess()
        {
            ob_start();
        }
 
        public function PostProcess()
        {
            echo "<i>" . ob_get_clean() . "</i>";
        }
    }
}

Je peux imaginer en faire autant avec mes sessions, mes droits d'accès aux ressources etc. Ensuite à la place d'écrire "bonjour", je dois analyser mon URL et lancer le contrôleur correspondant avec $this->o_Strategy->Execute();

Que pensez-vous de cette approche qui m'a l'air plutôt élégante ?

[batataw]

Franchement c'est dur a dire, cela dit ca correspond plus ou moins a ce qui se fait dans d'autres Frameworks.

En tout cas tiens nous au courant de tes avancés.

[batataw]

As-tu lu cet article?

http://julien-pauli.developpez.com/t...vc-controleur/

[ZeGuizmo]

Salut à tous,

J'apporte ma très modeste contribution en vous faisant partager mon expérience.

Il y a un peu plus de deux ans j'ai décidé de me lancer dans mon modèle MVC php. Pendant longtemps, c'est le pied. Y'a rien de mieux, on fait ce qu'on veut, rien n'est inutile, tout est sur mesure... Mais très rapidement je suis tombé dans un cercle vicieux : on en veut toujours plus. Deux ans et des dizaines de milliers de lignes de code plus tard, le frameworks est toujours en chantier, et je ne peux me résoudre à travailler avec tant que je ne l'estime pas terminé.

Du coup, j'ai jeté l'éponge, et je suis passé sur Kohana (code igniter version php5). Tout n'est pas perdu car on apprend énormément, mais un sentiment de gachi reste tout de même

[metagoto]

J'ai développé et testé plusieurs implémentation de MVC. Je précise tout de suite, uniquement en tant que hobby et aucun d'entre eux n'a véritablement été en production (parce que je n'en avais pas besoins)

Quand je parle de MVC, je devrais plutot parler de VC car mes diverses implémentations de M n'ont été que partielles.

Généralement, c'est l'arrivée de nouvelles features dans php qui me motivait pour tester des implémentations différentes. Par exemple le passage à php5 (et à cette époque je ne parlais pas encore de MVC). Puis l'arrivée de autoload, spl, les fonctions anonymes, les namespaces etc (je testais toujours les alpha et beta de php).

Si je dois résumer mon expérience en quelques mots:

- Pas de singleton: ça sert à rien. Autant utiliser une var globale. Complique (ou bride) les unit tests.

- Reporter au maximum si possible le routing (l'analyse de la requête) en amont de php: si le server peut le faire, laissons le faire.

- Eviter au maximum les traitement récurrents (du genre à chaque requêtes). Par exemple parser un fichier xml qui lui ne change pas. Mieux vaut le parser une fois et le transformer en un format le plus natif possible, comme un array par exemple.

- Eviter des require/includes(once) inutiles, donc bien utiliser l'autoload.

- Ne pas payer pour ce qu'on n'utilise pas. C'est à dire, plutôt que d'avoir une classe qui fait plein de trucs bien, il vaut mieux avoir plusieurs petites classes qui font un truc bien (la philosophie unix?) et les combiner. Par exemple plutôt que d'avoir un front controller qui teste en permanence si il y a une "vue" qui doit faire ceci ou cela, laisser la vue si elle est présente se gérer elle même dans le flow. La c'est un exemple avec la Vue, mais c'est pareil pour un composant de caching, d'authentification etc.

- Ne pas abuser des exceptions. Mieux vaut en mettre moins à de bons endroits plutôt que trop et partout. C'est couteux en performance.

Du coup, l'implémentation que je préfère:

- Server nginx qui fait office de server et de router. Possibilité de regex router: les expressions sont compilées une fois au démarrage ou au reload et le gain en performance est tout de suite visible. php reçoit directement une 'route' prête à l'emploi.

- Une sorte de front controller qui ne fait que dispatcher (fire) des events. Tous les composants dont j'ai besoins se greffent autour avec le mécanisme observer. C'est à dire la vue, les actions, le cache, les authentifications, les sessions etc.

- Une vue qui est du php. Les templates sont en php (ou alors elles sont 'transformées' en php une seule fois puis mise en cache/sauvegardées).

- Utilisation d'APC et memcached. D'une manière générale, privilégier les fonctions et extensions php plutôt que le même code en php 'a la main'.

[batataw]

Chapeau Megatoto, ton experience est tres interéssante. Je travaille sur un site web a haut trafic, ca m'a donné des idées.

Pourquoi ne t'es tu que tres peu investi dans la partie model?

[metagoto]

Pourquoi ne t'es tu que tres peu investi dans la partie model?

Parce que implémenter un Model - comprendre une librairie ou un partie de framework aidant à l'intégration du 'M' dans un MVC - est plus fastidieux et plus long à réaliser. Je perdais tout simplement ma motivation, alors que la partie 'VC' peut être prototypé beaucoup plus rapidement.