Hey, great question Andrei - I personally tend to favor using plain objects and functions over using classes. In general, I try to follow the mantra of "don't use a class where a function will work just as well". I've seen the bad things that can happen when classes get inherited too much and creates complex understanding of what 'this' refers to, having to trace back up the class hierarchy, etc.
That being said, I think there are two things to consider: 1) if you're working on a team that is more familiar with the class-based approach, then it's probably worth using that approach (although it's definitely worth discussing with your team if classes are really needed are not). 2) sometimes Services need setup in the constructor and/or to maintain state. That is a more valid use case for a class (although you could look into using a factory function instead if you have some complex setup).
Either way - classes/OOP vs just functions - the structure/code organization is what I think is most important. And not putting business logic in the controllers.
Thank you for your answer!
Initially I was going for plain objects, but then I realized that I would repeat the same functions for almost each service(same goes for controllers).
So I thought I would use a single blueprint service class and in the constructor I would choose the right db class using a factory pattern(that’s at least how I see things, it seems to be working well).
Anyway, I make sure that business logic goes into services, and the controller is the ‘orchestrator’.
Best of luck!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.