Attention, le contenu cet article est peut-être obsolète !
Quelques rappels sur l'architecture pattern MVC et les différentes couches du modelL'architecture-pattern MVC est celui le plus utilisé pour les gros sites / grosses applications Web. En effet, malgré sa lourdeur, il reste celui qui est le plus flexible, le plus ouvert à la maintenance, et ce n'est pas pour rien que les principaux framworks comme Zend ou Symfony l'utilisent.
Voici quelques rappels sur la partie données de ce pattern : le model (ou modèle).
Dans l'architecture-pattern MVC, Le model contient la couche métier, alors que la vue contient tout ce qui concerne la présentation des données et des interactions avec l'utilisateur, et que le controlleur gère toutes les interactions de l'utilisateur en provenance de la vue, via des méthodes (fonctions) implémentées. Car oui, un "vrai" MVC = POO.
Je dis ça, car il m'arrive de réaliser des petits sites, avec un découpage vue/données, mais ce n'est pas du MVC, juste un lien de parenté.
Donc le modèle contient la logique métier.
Quand on parle simplement du MVC, la couche modèle peut être présentée comme tout ce qui concerne les « données ». On entend par là tout ce qui va être persistant, c’est-à-dire tout ce qu’on pourra lire à partir d’une source quelque soit sa nature, et modifier ces données pour le relire plus tard si nécessaire.
Mais pour être plus précis, il faut savoir que le fait de manipuler ces données de manière brute, rend très difficile leur exploitationLeur modèle aura donc aussi pour objectif de manipuler et transformer ces données afin de les rendre facilement exploitable par le Controlleur. Il va donc falloir découper et traiter nos données avec des sous-couches.
Il y a trois couches d'abstraction :
La DAL permet de faire abstraction du support de données. Ainsi du point de vue de la théorie, peu importe le type de données: base SQL, fichiers XML, fichiers texte, le DAL permet de manipuler ces données.
Pour pouvoir permettre cela, le DAL présente des méthodes permettant d'accomplir les fonctions, notamment les plus communes du type CRUD : CREATE - READ - UPDATE - DELETE.
€€‹€€‹
Le but du DAO est de tranformer les données gérées par le DAL en objets facilement manipulable. Quand on dit objet, on parle de classes instanciées...
Il crée ainsi un objet en faisant correspondre les attributs de cet objet avec les données lues par le DAL.
€€‹
L'ORM a pour but de restituer les liens entre les tables (dans le cas d'une BDD) en créant les même liens entre les objets créés par le DAO. Il aura aussi pour but de faire l'inverse dans le cas de la sauvegarde de données sur le support.