The original post: /r/php by /u/P4nni on 2024-12-10 21:05:36.
Hello everyone,
I'm currently working on a project that has these basic entities:
CompanyUserInquiry
To retrieve and save those entities, I built Repositories according to the repository pattern.
Implementing the Repositories for the Company and User entities was simple, as those entities do not contain any other entities.
But now I'm planning the implementation of the InquiryRepository.
An Inquiry has a sender (User entity) and a receiver (Company entity).
So in order to instantiate an Inquiry the InquiryRepository has to query the CompanyRepository and the UserRepository.
This means at least 3 queries will hit the database to instantiate an Inquiry entity.
Those three database queries may not seem like a lot at first.
But the frontend should list around 20 Inquiry entities at once in the users profile.
With 3 database queries per Inquiry, we are at around 60 database queries per page load.
Some of those queries are even unnecessary as the sender will always be the current user.
This feels like way to many queries to me, so I'm thinking about runtime caching already instantiated entities.
But the benefits of caching may come with a truckload of more problems.
Having to think about all those (probably already solved) problems, makes me feel like I'm building my own makeshift ORM.
Now I'm wondering about these things:
-
Is this feeling correct or am I just overthinking?
-
Are those 60 database queries not a problem at all and I just shouldn't care or just cache the final 20 inquiries?
-
Am I implementing/understanding the repository pattern wrong?
-
Is it normal to built all those things or should I just use a fully fledged ORM like Doctrine?
In previous projects we used (and abused) the Active Record pattern.
Entities themselfs query all database tables they need data from, to reduce the total number of database queries.
Therefore I don't have much experience with the Repository pattern and ORMs.
I'd like to hear about your suggestions and experiences.