Doctrine et son utilisation

Question

Quelqu'un peut-il me dire 'Qu'est-ce que la doctrine n'est pas bonne? Veuillez décrire un scénario dans lequel nous n'utiliserions certainement pas Doctrine.

Answer 1

C'est certainement plus un ORM-ou-non? discussion. Je dirais qu'il y a des raisons architecturales et des raisons de performance de ne pas utiliser Doctrine.

Le but d'un ORM est de traduire la structure de la table de base de données en graphes d'objets pour votre application. Si vos données sont censées représenter ou «modéliser» discriminer des objets ou des relations entre des objets (Utilisateur, Panier, Commande, etc.). alors un ORM est un outil précieux.

Mais dans le cas où votre application travaille avec des données tabulaires, et il n'y a pas de impedence mismatch sérieux, Doctrine pourrait ne pas être la bonne approche. Par exemple, si mon application devait fonctionner avec de grands ensembles de fichiers journaux, un ORM peut être excessif. De plus, si votre base de données est fortement dénormalisée, un ORM n'est probablement pas pour vous.

Il existe également des critères de performance. Les ORM ont tendance à être plus lents que l'utilisation de SQL à chaud. La doctrine a aussi l'habitude de construire de très gros graphiques d'objets plutôt que d'avoir une grande empreinte mémoire. Il n'est pas vraiment well suited de travailler avec des milliers de lignes de base de données à la fois, ou avec un nombre élevé d'insertions, de mises à jour ou de suppressions. Si vous devez traiter une grande quantité de transactions de base de données, un ORM peut ne pas vous convenir. Ma philosophie est qu'un ORM est un outil extrêmement utile jusqu'à ce qu'il devienne trop douloureux à utiliser. Si vous ne pouvez pas du tout tirer profit de Doctrine, vous le connaissez probablement déjà.