Principes de conception de classe PHP MongoDB

Question

Je travaille sur le développement d'une API. J'ai commencé avec un concept l'année dernière et je l'ai développé depuis. Au cours de l'année, la structure et les offres ont beaucoup changé et je trouve que c'est un casse-tête de mettre à jour mes structures de classe. Accordé, j'ai commencé à concevoir ce nouveau à PHP et à MongoDB, également nouveau au concept de la programmation de Web et aux serveurs obtenant et envoyant des données et des bases de données en général. J'ai une bonne compréhension de la façon dont les deux travaillent ensemble maintenant, mais je crois que mon approche initiale de la conception de classe est erronée. Eh bien, je suppose que ce n'est pas faux, mais pas conçu aussi bien qu'il devrait l'être.

Actuellement, j'ai 4 classes principales. Nous les appellerons les classes A, B, C et D.
Maintenant, les classes A, B et C sont tous les objets qui représentent les documents qui sont stockés dans 3 collections MongoDB distinctes. La classe D représente une classe de monstres qui gère les interactions entre les trois autres objets. J'ai senti que c'était mal d'avoir des objets qui modifient d'autres objets à l'intérieur d'eux.

Les objets A, B et C ont tous des connexions à MongoDB à l'intérieur de leur fonction __construct(). Est-ce une approche correcte? Est-ce une bonne pratique que l'objet gère sa propre connexion à la base de données?

Merci d'avance pour l'aide!

Answer 1

Ceci est généralement une mauvaise idée à moins que vous n'ayez un gestionnaire de connexions de regroupement à partir duquel les objets acquièrent leurs connexions. La configuration de la connexion est coûteuse et vous disposez d'un nombre limité d'emplacements de connexion.

De manière générale, vous aurez besoin d'une connexion par thread, que les objets utiliseront ensuite. Cela peut varier en fonction des besoins de votre application, mais au minimum, utilisez un pool de connexions plutôt qu'une connexion par instance.