Pourquoi MVC sur les sites web ?
|
Quel est l'avantage principale à utiliser le pattern MVC (Modèle-Vue-Controleur) lors de la création d'un site web. La plupart des frameworks web (en PHP, Python, Ruby, Java, ...) implémente tous ce patron de conception. Pourquoi ?
|
|
Parmi la longue liste d'avantages, le plus évident semble être la séparation des couches logiques du développement d'une application ou d'un site, et donc de clarifier le travail (et le code). En effet, MVC de par sa nature Modèle/Vue/Contrôleur revient à demander aux développeurs et contributeurs de faire une distinction nette des données, du rendu, et des actions métiers. Ainsi, un graphiste n'a pas besoin d'avoir de notions de développement, et inversement, les modifications d'un développeur ne remettent pas directement en question le rendu. De plus, le stockage des données tend vers la transparence et offre des fonctions génériques qui en simplifient l'accès et l'édition. On peut alors aisément multiplier les sources de données (via différentes BDD, ou fichiers ayant des formats variés), ainsi que les formats de sortie (xHTML, XML, CSV, RSS...) sans impacter la lisibilité et l'accessibilité du projet pour chacun des participants. Toujours en suivant ce raisonnement, il est alors possible (théoriquement) de porter l'algorithme d'une application sur n'importe quel langage, voir même lors d'une migration d'un langage à l'autre (ou entre deux versions majeures d'un même langage) d'avoir à concentrer son attention essentiellement sur le code métier, et donc le cœur de l'application. Editer: 30 juin 2011, 16:56
|
|
Initialement il s'assagissait de découpler chaque couche les unes des autres pour les rendre les plus indépendantes possible, ça c'est râté, du coup ils ont fait toute une série de constructions qui en dérivent. La structures la plus utilisée est les MVC2 (ou MVCC) avec le rajout d'un Contrôleur frontale dans le but d'alléger tous les contrôleurs. Des frameworks tente de décoreller les couches en en rajoutant, ce qui fait qu'au lieu d'avoir une vue on a un layout (l'équivalent d'un contrôleur frontal pour les vues), la vue en elle-même, les helpers et les partials. Pour les contrôleurs on a le contrôleur, les helper, les ActionHelper (pour factoriser/simplifier les contrôleurs). Pour les modèles (donc la partie métier) on a le modèle en lui même (avec des getter, des setters et la logique métier, on a le mapper qui fait le liens avec la DAL (Data Access Layer, couche d'accès aux données), qui elle est constitué d'un objet pour la Table, un pour les jeux d'enregistrements, un pour les enregistrements et même pour les requêtes. Si tu rajoute à ça les formulaires et toutes les fonctionnalités basique, comme la pagination, tu te trouver avec pas loins d'une douzaines voire une quinzaines d'objets, donc autant de fichiers, pour faire un CRUD. |

Flux de la question