J'avais l'habitude d'écrire les fonctionnalités d'accès aux données dans le modèle lui-même. Maintenant, je veux séparer l'accès aux données de la logique métier. J'utilise codeigniter comme framework. Il semble que l'une des façons de le faire est d'utiliser ORM, mais j'imagine qu'il y aura une pénalité de performance.comment séparer la couche d'accès aux données dans le codeigniter
Y a-t-il des bonnes pratiques générales?
Jetez un oeil à la source de données modèles architecturaux de POEAA:
CodeIgniter prétend utiliser ActiveRecord, but it doesnt. C'est plutôt comme un QueryObject rudimentaire. Pour vraiment séparer votre DAO de vos objets de domaine, vous devez utiliser un DataMapper. En fonction de la complexité de vos besoins de mappage, vous pouvez en créer un vous-même ou utiliser un . Ironiquement, la majorité des ORM dans le monde PHP sont basés sur ActiveRecord, which is pretty ill-suited for ORM. Doctrine 2 est le seul que je connaisse qui utilise une approche DataMapper. Un ORM aura toujours une pénalité de performance (et cela peut être sérieux). Cependant, vous ne devriez pas exclure un ORM juste à cause de cela. Handcrafting un DataMapper efficace dans un scénario élevé impedance mismatch peut être un travail fastidieux et difficile. Encore une fois, voir POEAA pour une liste des modèles Object-Relation courants.
Il semble y avoir un DataMapper implementation for CodeIgniter with Overzealous DMZ. Je n'ai jamais travaillé avec et je ne peux rien dire à ce sujet. Il est juste venu après un google rapide, donc j'ai pensé que je l'ajoute ici.