1.3. Construisons notre framework PHP

Il existe de nombreuses manières de concevoir un framework. Certains préfèrent des frameworks très complexes, d’autres très simples. Dans nos articles, nous allons rapidement créer un framework simple à utiliser et facile à comprendre.

Nos articles vous aideront à développer votre propre framework, différent de celui dont nous avons besoin pour créer une boutique en ligne, vous pourrez facilement ajouter d’autres parties au framework pour créer quelque chose de plus grand. L’objectif principal de cette série d’articles est d’apprendre à créer votre propre framework pour n’importe quel CMS.

Patterns (Modèles)

Pour développer un framework, différents modèles de conception (design patterns) sont utilisés. Un pattern est une solution éprouvée et une bonne pratique pour résoudre des problèmes courants liés au développement logiciel. Parmi les patterns que nous utiliserons, on trouve :

• Modèle-Vue-Contrôleur (MVC, Model-View-Controller)
• Registre (Registry)
• Singleton (Classe unique)

Modèle-Vue-Contrôleur (MVC)

MVC est la base de notre framework, il nous permet de séparer l’interface utilisateur de la logique de notre application. L’interface utilisateur (View) interagit avec les modèles de données (Model) en passant par les contrôleurs (Controller), qui contiennent la logique métier nécessaire pour gérer les données dans les modèles.

Par exemple, quand un utilisateur clique sur « Ajouter au panier » dans la Vue, le contrôleur traite cette requête, interagit avec le modèle panier pour ajouter un produit. Généralement, les données du modèle panier retournent au contrôleur le nombre actuel d’articles dans le panier, et la nouvelle vue affiche le panier avec le nouveau nombre d’articles.

Nous utiliserons notre framework et pourrons étendre les fonctionnalités basées sur MVC. Comme décrit précédemment, les données sont dans les modèles, et elles sont stockées dans la base de données. Les modèles et les tables de la base ont la même structure (les champs des modèles correspondent aux champs des tables). Nous pouvons donc étendre notre diagramme MVC. Nous voyons aussi que le résultat final, traité dans la Vue, est affiché dans le navigateur, donc nous l’ajoutons au diagramme.

Registre (Registry)

Le Registre permet de stocker une collection d’objets de notre framework. Le besoin d’un Registre découle de l’abstraction liée au pattern MVC. Chaque contrôleur et modèle (par exemple produit, panier, page) doit réaliser des tâches communes, telles que :

• Requêtes à la base de données
• Vérification si l’utilisateur est authentifié pour accéder aux données
• Envoi de données à la Vue (gestion des templates)
• Envoi d’e-mails, par exemple lors de l’achat d’un produit
• Interaction avec le système de fichiers, par exemple chargement de photos de produits

La plupart des systèmes et frameworks accomplissent ces fonctions via des objets, et nous créerons de tels objets. Le Registre permet de stocker ces objets ensemble. Il peut être appelé depuis n’importe quel endroit du framework et donne accès à ses fonctions. Voici un diagramme approximatif de notre Registre.

Le framework interagit directement avec le Registre, qui fournit ensuite l’accès aux autres objets. À l’intérieur du Registre, les objets peuvent aussi interagir entre eux, par exemple le gestionnaire de templates peut être lié au gestionnaire de fichiers, l’envoi d’e-mails lié aux templates d’e-mail.

Singleton (Classe unique)

En français, il est difficile de trouver un terme pour "singleton", nous utiliserons « classe unique », même si la documentation utilise souvent le terme anglais « singleton ».

La classe unique est l’un des patterns les plus simples à comprendre. Son but principal est de garantir qu’il n’existe qu’une seule instance d’une classe. Cela est nécessaire généralement lorsqu’un seul objet de cette classe est requis et doit être accessible globalement dans l’application.

La classe unique est utilisée lorsqu’une classe a une seule responsabilité, par exemple gérer la connexion à la base de données, afin que tous les autres objets puissent interagir avec la base via cette instance unique.

Structure générale

La prochaine étape dans le développement de notre framework est la planification de sa structure. Nous devons créer une structure pour :

• Les modèles
• Les vues (pour pouvoir intégrer la possibilité de changer le style du site dans notre framework, chaque style aura son propre dossier)
• Les contrôleurs (pour stocker les contrôleurs dans un dossier séparé, afin que pour ajouter des fonctionnalités il suffise d’ajouter un nouveau dossier de contrôleur)
• Les contrôleurs d’administration (nous créons non seulement un framework, mais aussi un CMS, il faut donc prévoir que les modérateurs et admins puissent modifier les contenus)
• Le registre
• Les objets du registre
• Les fichiers uploadés
• Les bibliothèques tierces
• Autres codes

Compte tenu de la structure du framework, les dossiers de notre framework seront les suivants (nous utiliserons les noms en anglais, comme c’est la norme en PHP) :

• Models
• Views
  • View A
  • Templates
  • Images
  • JavaScript
• Controllers
  • Controller A
    • ControllerA
    • ControllerAAdmin
• Registry
  • Objects
  • Database objects
• Assets
• Uploads
  • À étendre lorsque nous ajouterons des produits et images à notre framework !
• Libraries
• Miscellaneous