Remplacement d'une couche de base de données locale par DBAL

Ahnii!

Contexte de la série : Il s'agit de la partie 7 de la série Waaseyaa. Cet article s'appuie sur le système d'entités et la couche API du début de la série.

Chaque framework finit par devenir trop grand pour sa première abstraction de base de données. WaaseyaaBase de données Pdoclass nous a bien servi jusqu'à la v0.1.0, mais au moment où trois applications en dépendaient, les fissures sont apparues. Cet article couvre la migration vers Doctrine DBAL – 67 commits sur trois semaines – et comment les trois applications ont été mises à niveau sans un seul changement radical au niveau de la couche application.

Pourquoi remplacer une couche de base de données fonctionnelle

Base de données Pdoétait un mince wrapper autour du PDO de PHP. Il gérait les connexions, les instructions préparées et la prise en charge de base des transactions. C'était suffisant pour démarrer le framework.

Mais à mesure que le système d'entités mûrissait, nous avions besoin de chosesBase de données PdoJe ne pouvais pas fournir. Il n'y avait pas d'abstraction du générateur de requêtes : chaque requête était une chaîne SQL assemblée à la main. Il n’y avait pas d’introspection de schéma, nous ne pouvions donc pas inspecter les tables ou les colonnes par programme. Il n'existait aucun outil de migration, les modifications de schéma étaient donc des scripts SQL ad hoc. Et il n'existait aucun moyen systématique de gérer les différences entre SQLite (utilisé dans les tests) et MySQL (utilisé en production).

Ce ne sont pas des exigences exotiques. Ce sont des enjeux de table pour un cadre dont dépendent plusieurs applications.

Ce que DBAL vous apporte

Doctrine DBAL est la couche d'abstraction de base de données...
[Courte citation de 8% de l'article original]