Dans PHP, quelle est la meilleure pratique pour définir les responsabilités d'un Db Abstraction Layer?Où commencent et se terminent les responsabilités d'une Abstraction Db en PHP?
Est-ce que OOP est une bonne idée en termes de performance? Combien devrait être le code objet générique, et combien devrait être des fonctions très spécifiques?
Dans la plupart des applications que j'ai écrites, il y a généralement deux types différents d'accès aux données. La première concerne les opérations transactionnelles: récupérer des objets spécifiques à partir du magasin de données, les modifier et les sauvegarder. J'ai trouvé un ORM solide pour être la meilleure solution ici. N'essayez pas d'écrire le vôtre (aussi intéressant que cela puisse être).
L'autre type commun d'accès aux données est le reporting. Les ORM ne sont pas la meilleure solution ici, c'est pourquoi je vais généralement avec un système qui utilise des requêtes SQL personnalisées. Plain ol 'AOP fonctionne bien ici. Vous pouvez créer un objet de valeur spéciale juste pour ce rapport et demander à la requête PDO d'extraire les valeurs dans l'objet. Les rapports doivent être rapides et leur construction à l'aide d'une couche ORM est généralement trop lente et fastidieuse.
Il existe déjà d'excellentes solutions pour cela. Un DAL n'est pas une chose simple, d'autant plus que beaucoup de problèmes de sécurité sont impliqués. Je suggère de vérifier PDO et MySQLi. Même si vous écrivez une classe wrapper pour l'un d'entre eux, le gros travail sera fait pour vous d'une manière robuste et sécurisée.