Discussion :

[symfolive]

Modèle MVC

Le modèle « Modèle Vue Contrôleur » est très répandu dans le développement d’applications et occupe également une place importante dans le développement web. Il permet de structurer une application en distinguant la partie présentation d’une part et le code applicatif d’autre part, ce qui facilite le développement en équipe, la relecture et la maintenance. Dans le contexte d’une application web, on obtient les éléments suivants :

• Modèle : ce sont les données manipulées par le site (les données stockées en base – correspondent au mapping ORM, que l’on abordera plus loin)
• Vue : ce sont les différentes pages du site, qui affichent les informations. Le rôle de « vue » est généralement rempli par des templates.
• Contrôleur : le traitement des actions utilisateurs. Dans un contexte web, on utilise généralement un contrôleur frontal (Front-Controller) qui reçoit directement les requêtes utilisateur (URL et paramètres) et qui se charge d’exécuter le code adapté : les actions. Les correspondances entre les URL et les différentesactions sont spécifiées par le développeur et sont souvent appelées « routes » dans les frameworks PHP.

Code :

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

// Exemple de route http://www.monsite.fr/news/list/start/10 -> Controleur : news -> Action : list -> Paramètre : start=10

Le modèle MVC a fait depuis longtemps ses preuves dans le monde Java
avec Struts, Spring, WebWork…

Événements

La programmation événementielle est un modèle différent du modèle MVC qui est surtout pratiqué dans le développement d’applications de type « client-lourd » qui s’exécutent sur le poste de travail de l’utilisateur.

Chaque élément de la page (boutons, liens, champs texte…) dispose d’événements correspondant par exemple au clic, à la modification ou à la sélection de l’objet auxquels il est possible d’associer différentes fonctions.

Ce modèle encourage l’utilisation de composants indépendants tels que des formulaires d’authentification, ou des listes d’éléments qui intègre les fonctions de tri et de pagination.

Templates

Les templates (gabarits) rentrent dans le processus de la séparation du code applicatif et de la présentation.
Une template est un fichier contenant essentiellement du code HTML complété de quelques commandes pour l’affichage d’informations issues du code métier. Il est également possible d’utiliser des templates différents pour
l’interface générale du site et pour la mise en page des contenus. Un template peut inclure d’autres templates, ce qui permet de mutualiser certaines parties des pages.

L’intérêt des templates :

• La présentation est séparée du code applicatif : il est possible de la modifier sans se préoccuper du traitement des données et inversement.
• La création des templates peut être confiée à des graphistes, car elle ne nécessite que très peu de connaissances techniques PHP.
• Il est possible de combiner des templates simples pour former une template plus complexe, et ainsi réutiliser le code au maximum.

Cache
Un système de cache permet de stocker le résultat de l’affichage de certaines pages ou d’actions utilisateur afin de le réutiliser directement lors du prochain accès. La montée en charge des applications s’en trouve améliorée, et les temps d’exécution se rapprochent des pages statiques.

Il est souvent possible de déclarer un cache pour des pages entières ou uniquement pour certaines zones.

Accès aux données

Les applications web accèdent pratiquement à chaque clic à une base de données. L’accès au données est donc une fonctionnalité essentielle, mais également critique et gourmande en temps de développement lorsqu’on utilise uniquement les fonctions standard de PHP.

Type de base de données

Un premier problème est l’indépendance vis à vis de la base de données. Même si MySQL est la base la plus utilisée dans les applications PHP, on souhaite généralement pouvoir remplacer la base de données lorsque cela est necessaire. Malheureusement, PHP utilise des API différentes pour chaque base et on constate que l’implémentations du langage SQL change suffisamment pour empêcher le fonctionnement de l’application avec une base différente que celle avec laquelle elle a été développée.

Un framework peut donc proposer une API unique et des fonctions de création de requêtes SQL, qui génèrent du code SQL adapté à la base de donnée utilisée. La simple modification d’un fichier de configuration permet alors de changer le type de base utilisé.

Mapping de relationnal object

Le framework peut également proposer une fonctionnalité d’ORM (Object Relationnal Mapping), c’est à dire qu’il permet masquer la complexité du langage SQL et d’effectuer la plupart des opération par l’intermédiaire d’objets très simples, ce qui allège significativement le travail du développeur.

Traditionnellement, un ORM demande un peu de configuration pour créer et enregistrer dans l’application des objets très simples appelés DAO (Data Access Object) qui représentent un élément d’une table donnée. La plupart des implémentations permettent de générer la configuration et les objets directement à partir de la structure de la base elle-même.

L’ORM tel que l’implémente Ruby on Rails sous le nom d’ActiveRecord ne nécessite aucune configuration et inspecte la base de données pour créer les différents objets. Le développement et la maintenance s’en trouvent grandement simplifiés au prix d’une légère perte de performances.

Code :

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

// Insertion d’une entrée dans une table		                commentaire = new Commentaire();		commentaire->setTitre( « Mon titre »);		commentaire->setCorps( « Mon commentaire »);		commentaire->save();		// Obtenir toutes les entrées d’une table		commentaires = Commentaire.findAll();

L’objectif de l’ORM n’est pas de remplacer ou de masquer complètement le langage SQL, mais de prendre en charge la majorité des requêtes utilisées dans l’application. Pour les requêtes les plus complexes ou les plus critiques en vitesse d’exécution, le développeur peut choisir d’utiliser directement le langage SQL si cela est nécessaire.

Conventions

Pendant le développement d’une application, un ensemble de règles sont généralement définies concernant le noms des fichiers ou leur emplacement.

L’utilisation de conventions au niveau du framework permet d’utiliser ces règles pour configurer et lier implicitement les différents modules et classes de l’application, ce qui a pour effet de diminuer le nombre et le volume des fichiers de configuration dans l’application.

Des étapes de configuration sont seulement nécessaires lorsqu’on souhaite s’écarter des réglages par défaut.

La mise en place de conventions prend tout son intérêt lorsqu’elle est couplée à de la génération de code.

Génération de code

La mise en place d’un nouveau projet demande généralement la mise en place d’une structure globale et la création de nombreux fichiers.

La génération de code est utilisée pour gagner du temps grâce à l’initialisation automatique de la structure d’une application et à la création et déclaration de nouveaux éléments ou plugins via une simple ligne de commande.

Echafaudage

« L’échafaudage » (ou scaffolding) ajoute sans aucun développement une interface d’administration qui permet l’affichage, l’ajout, la suppression et l’édition d’éléments contenus dans une table de la base de données.

Fortement lié, à la fonctionnalité d’ORM, il permet d’obtenir instantanément une interface temporaire qui pourra plus tard être remplacée par une interface plus évoluée.

En général cette interface est générée à la volée par le framework sans qu’aucun code ne soit présent dans l’application. Il est cependant possible de demander la création du code correspondant et de s’en servir de base pour le développement de la véritable interface.

Gestion des droits

Le framework peut offrir des méthodes pour définir les rôles des utilisateurs ainsi que les droits nécessaires pour exécuter chaque opération. Il se charge ensuite de vérifier les autorisations à chaque appel d’action et de bloquer l’exécution si nécessaire.

URL conviviales

Les applications web dynamiques utilisent généralement des paramètres dans les adresses (URL) pour transmettre des informations de page en page.

Les URL obtenues sont difficilement lisibles et ne sont pas très adaptées à l’indexation effectuée par les moteurs de recherches.

Les urls conviviales donnent l’impression à l’utilisateur (ou au moteur d’indexation) d’avoir affaire à un site statique :

http://www.monsite.fr/index.php?modu...ms&action=list

devient

http://www.monsite.fr/index.php/items/list

et même , si l’on a la possibilité de modifier la configuration du serveur web :

http://www.monsite.fr/items/list

Ces type d’URL sont souhaitables à la fois pour un bon référencement et pour le confort des visiteurs.

Ajax

AJAX est le nom donné à l’utilisation de Javascript dans un site afin de mettre à jour de façon asynchrone le contenu de certaines parties d’une page.

Un framework prend en charge les fonctionnalités de base de l’application web, ce qui rend difficile de concevoir des requêtes Ajax si le framework n’en prévoit pas l’utilisation.

Le support d’Ajax peut être complété par l’intégration d’une ou plusieurs bibliothèques ( prototype, script.aculo.us, YUI, …)., ce qui facilite leur utilisation.
Php Frameworks@@AMEPARAM@@ssplayer2.swf?doc=phpframeworks-090516151727-phpapp02&stripped_title=php-frameworks@@AMEPARAM@@phpframeworks-090516151727-phpapp02@@AMEPARAM@@php-frameworksView more presentations de Ryan Davis.

Billet original sur Symfolive

[Fenn_]

Modèle MVC

Le modèle « Modèle Vue Contrôleur » est très répandu dans le développement d’applications et occupe également une place importante dans le développement web. Il permet de structurer une application en distinguant la partie présentation d’une part et le code applicatif d’autre part, ce qui facilite le développement en équipe, la relecture et la
maintenance. Dans le contexte d’une application web, on obtient les éléments
suivants :

• Modèle : ce sont les données manipulées par le site (les données stockées en base – correspondent au mapping ORM, que l’on abordera plus loin)

Je dis peut-être une ânerie, mais il me semblait que dans le modèle MVC, la partie modèle regroupait (à plus ou moins fort degré, surtout dans une appli web) couche d'accès au données + objets métier. Donc "l'accès aux données et leur manipulation" plutôt que "les données manipulées".
Je me goure? (juste pour ma culture perso, pas pour polémiquer)

[tontonnux]

Je dis peut-être une ânerie, mais il me semblait que dans le modèle MVC, la partie modèle regroupait (à plus ou moins fort degré, surtout dans une appli web) couche d'accès au données + objets métier. Donc "l'accès aux données et leur manipulation" plutôt que "les données manipulées".
Je me goure? (juste pour ma culture perso, pas pour polémiquer)

Avec symfony (surtout avec l'ORM intégré en fait) on a bien une séparation des couches "données" et "métier". Les 3 niveaux M, V et C sont clairement identifiés et séparés.

[Fenn_]

Merci pour la réponse, je note ^^

[shadypierre]

* Modèle : ce sont les données manipulées par le site (les données stockées en base – correspondent au mapping ORM, que l’on abordera plus loin)
* Vue : ce sont les différentes pages du site, qui affichent les informations. Le rôle de « vue » est généralement rempli par des templates.
* Contrôleur : le traitement des actions utilisateurs. Dans un contexte web, on utilise généralement un contrôleur frontal (Front-Controller) qui reçoit directement les requêtes utilisateur (URL et paramètres) et qui se charge d’exécuter le code adapté : les actions. Les correspondances entre les URL et les différentesactions sont spécifiées par le développeur et sont souvent appelées « routes » dans les frameworks PHP.

C'est l'explication de ce qu'est la méthode MVC la plus clair que j'ai pu lire, bravo

[Michel Rotta]

En fait la séparation des couches n'est pas aussi évidente que cela. Il y a une légère confusion entre la C et le V.

En effet, dans le code, on prépare un objet form, avec des widgets. Hors ces Widgets sont responsables de l'affichage et de la génération du code XHTML qui correspond aux Widgets, plus encore, les éventuelles paramètres XHTML sont généralement mis en place dans la méthode config() du form. Hors on peu considérer que les objets forms font partie de la couche C et non de la couche V mais sont responsables d'une bonne partie du code généré par la couche V.

D'où une légère entorse à la règle.

[elderion]

Non en effet la separation des couches C et V n'est pas evidence tellement ces 2 entités travaillent ensemble.
Comme alternative
on peut aussi utiliser des méthode statiques du controleur qu'on appelle dans la vue.
Ou carrément paser la référence d'un controller a une vue. Je suis pas sur que ca soit une facon de faire.
Personnellement je n'ai pas de vraie bonne méthode pour bien séparer les 2.
Mais si quelqu'un a une méthode qui marche bien je suis preneur

Toujours a propos de separation des couches : ya un truc qui m'étonne beaucoupau niveau de la View / Template : Symfony melange du code dans les templates HTML.
Ca me parait incohérent. On devrait passer par des tags genre [REPLACE_ME] dans le HTML qu'on remplace par des valeurs en PHP avec un preg_replace(), quelque chose comme ca. J'ai etsét ca marcehe bien. Templates plus lisibiles, perfs pareil.
Le probleme aussi de mettre du code PHP dans des templates HTML, c'est que la notion de portée est rompue.
On se retrouve avec $foo ou des $foo->bar sans potée explicite.
Smartu prone la separation du PHP et du HTML, mais impose l'utilisation d'un pseudo code a la place. Ce qui revient au meme.

[Michel Rotta]

Il y a bien une solution pour les Widget de les mettre a cheval élégamment sur les couches C et V. Faire en sorte que le widget utilise un partial pour générer l'affichage. C'est aussi vrais que, quant on affiche champ par champ on peut mettre, dans le V des paramètres XHTML pour influencer le code XHTML généré.

Par contre, pour ce qui est du code dans les templates, il n'y a pas beaucoup de solutions.

Soit on utilise du code php dans le template, au minimum et avec des données préparées par la couche C. L'autre solution est d'inventer des TAG spéciaux, plus d'autre pour des if, plus d'autres pour des boucles... et on se retrouve avec un smarty. Mais l'avantage n'est pas certains, en effet, cela implique un moteur supplémentaire qui va interpréter ce pseudo code et rajouter du temps de traitement. Sans compter le fait d'avoir un nouveau langage à apprendre et maîtriser.

Certains passent alors par une pseudo compilation qui remplace le code du moteur de template par du php et exécute ce fichier, plus rapide en traitement.

Je pense que la manière utilisée par symfony est bonne.

Maintenant, dans la version 2, un moteur de template a fait son apparition... A voir (je n'ai pas encore vu).

[eric.quinton]

En ce qui concerne le MVC, il y a en fait une approche "outil" qui fait que l'on mélange allègrement les objets manipulés dans les différentes rubriques MVC...

La vue correspond à ce qui est transmis à l'utilisateur : c'est l'affichage, que l'on gère de préférence par l'intermédiaire de moteurs de gabarits (templates), mais pas que ! L'envoi d'un fichier PDF, par exemple, est du ressort de la vue. Le principe, c'est qu'une information est fournie par le modèle, et la vue décide de sa mise en forme. On peut ainsi décider d'afficher différemment une information fournie par le modèle, en fonction du contexte : export au format PDF ou OpenOffice, par exemple, plutôt qu'un affichage de tableau.

Le contrôleur a pour rôle de :
- vérifier l'identité de l'utilisateur
- vérifier ses droits
- gérer l'enchaînement des différentes opérations dans l'application ; il peut ainsi décider d'enchaîner plusieurs modules, par exemple enregistrer une information en base de données, puis déclencher l'affichage d'une liste
- et c'est tout (ou presque).

Enfin, le modèle (le M), contient le reste, c'est à dire le code proprement dit, que celui-ci intègre ou non la manipulation de données. On confond souvent Modèle au sens MVC avec Modèle au sens relationnel, c'est à dire modèle de base de données. Cela n'a rien à voir : le modèle de MVC contient le code applicatif, qui intègre en général la manipulation des infos. La logique applicative, c'est à dire l'enchaînement des modules, est du ressort du contrôleur.

Les ORM, quant à eux, sont des mécanismes permettant de réaliser le couplage "relationnel-objet". En général, les ORM implémentés ne font que simplifier l'écriture des requêtes courantes (CRUD : create, read, update, delete), souvent en singeant le SQL. Par exemple, ils distinguent l'opération de création de celle de mise à jour, alors que dans la pratique, si on utilise des clés uniques, ces deux opérations peuvent être regroupées en une seule, à savoir Ecrire. C'est alors au composant ORM de se débrouiller pour savoir ce qu'il doit faire (un insert ou un update).

Mais quand on réalise une analyse objet, il n'est pas toujours évident qu'à une table de la base de données corresponde un objet. Dans un certain nombre de cas, un objet peut manipuler des informations issues de différentes tables. L'ORM devrait alors être capable de gérer la manipulation entre l'objet applicatif et les différentes tables de la base de données. Dans la pratique, pour faire simple, les ORM réalisent un couplage de type un-un entre un objet et une table.

Si ce sujet vous intéresse, je vous conseille la lecture du livre :
PHP - de l'analyse au développement d'une application professionnelle, édité aux Editions ENI, qui aborde tous ces aspects.