mardi 4 janvier 2011

Considérations sur MVC


MVC est un pattern définit par un Modèle, un Viewer et un Controller. Pour faire simple:

Le schéma n'est pas des mieux pour l'instant mais globalement, le controlleur s'occuppe des entrées utilisateurs (requête, update, ...)
Le controlleur va donc créer un Modèle qui sera utilisé pour alimenter le viewer.
Le modèle quant à lui s'occupe de différentes choses
- validation
- accès aux données
- business logic
- structure des données à afficher (présentation)
Le viewer quant à lui affiche les sorties (rendu). Notez toutefois que le viewer est un observeur du Modèle. Donc si le modèle change, le viewer est automatiquement notifié et prié de ce mettre à jour. Et ce sans l'intervention du contrôleur.

Cette description est très simplifiée mais elle donne une idée rapide de ce qu'est MVC. A ce pattern on peut retrouver différents framework associé tels que Spring par exemple qui est utilisé pour implémenter MVC dans des applications Java.

Nous avons vu que le modèle (M) permet l'accès aux données, pour se faire on peut aussi utiliser un framework tel que Doctrine qui permet de simplifier le mapping des classes sur des tables (il joue le rôle des DBObject dans TrialXS).
Doctrine est un framework qui implémente le pattern Active Record (cfr Folwer)
Le pattern active record présente un certain nombre de défaut:
- mal fichu pour des queries complexe
- à chaque nouvelle table il faut une nouvelle classe

Il est toutefois déconseiller de n'utiliser que Doctrine comme modèle car chaque fois que l'on va créer un nouveau controlleur il faudra définir dans le controlleur la manière dont les données sont liées, là on s'éloigne de la philosophie MVC car la collaboration d'objets pour réaliser une fonction doit se trouver dans le modèle.
Le modèle abstrait la manière dont les données sont liées entre elles en fournissant une interface de functionalités.

De plus Active Record expose les méthodes CRUD (Create Read Update Delete). Dans certains cas ça peut créer des racourcis funestes... En effet si par exemple ajouter un nouveau user implique de mettre à jour une table d'historique, le fait d'accéder directement à la table user peut ommettre cet update (si il n'y a pas de trigger sur la table user...).

Aucun commentaire:

Enregistrer un commentaire