I read everything and its opposite about how to organize its code. Of course, I try to follow the SOLID principles, but since I consider myself quite a beginner, I would need some outside advice on how to put them into practice. This concerns the general architecture of the site which I detail the layers below :
- Controller (Define a request contract) -> Call a Proxy service
- Proxy service (Input validation, Caching and proceed to log some informations) -> Call concrete service
- Concrete service (Manage Business logic) -> Call Repository
- Repository (Query the database) -> Call Database
So those are the layers of my application! The part I am the least confident about is the Proxy service which is an implementation of the Proxy design pattern. Maybe Proxy service got to much Responsibility.
Also, I know this is maybe off-topic, but I don't understand the thing about Inversion of Dependency. I mean, should I really create an Interface for every Proxy service ? And so each interface will have such a lot of function!
Based on the Dependency Inversion Principle all business logic classes should implement a fine-grained interface in order to allow for multiple implementations. Source
But... I've read that Interface must be as small as possible.
So keep your interfaces small. You don't want an interface to have 30 methods on it, 3 is a much better goal. Source
And on the opposite I've also read that, as service are responsible for logical flow, that's ok if they contain a lot of functionality :
Note that service classes may appear to break the Single Responsibility Principle because they may call multiple classes from different layers and packages in a single method but this is because they model the logical flow of data and as such, this is a correct practice. Source
So finally I'm lost between all those informations and I need someone to push me in the good direction !