I agree that most business logic should not happen inside the controllers but I'd say that calling a database query like this is hardly "business" logic. I think I'd reserve applying the principle for real business invariants and algorithms, and avoid artificial creations like PostsFromDatabase here.
To add a little "it depends" factor, there is a good case for moving out simple orchestration logic like this out of the controllers. That's when (and only when) this logic needs to be reused in another place e.g. we do the same thing both in response to an HTTP request and when we receive an event via a message queue.
Hi Grzegorz, thanks for your comment.
I see that many devs do not see a problem in this particular example, at least nobody complains about that on Symfony website :)
I still believe that which posts coming from a database is business logic.
Let me elaborate on this. If you have method getPostsFromDatabase than you can explicitly specify in this method exact criteria which posts you want to show — for example only active, only newer than one week, etc. Query criteria is than, an example of business logic.
On the other hand, as you already mentioned, if we have to execute a database call from two different places, it has to go to a separate class.
I believe that keeping database calls in controllers are evil, no matter do we using it in some other places. What do you think about that?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree that most business logic should not happen inside the controllers but I'd say that calling a database query like this is hardly "business" logic. I think I'd reserve applying the principle for real business invariants and algorithms, and avoid artificial creations like
PostsFromDatabasehere.To add a little "it depends" factor, there is a good case for moving out simple orchestration logic like this out of the controllers. That's when (and only when) this logic needs to be reused in another place e.g. we do the same thing both in response to an HTTP request and when we receive an event via a message queue.
Hi Grzegorz, thanks for your comment.
I see that many devs do not see a problem in this particular example, at least nobody complains about that on Symfony website :)
I still believe that which posts coming from a database is business logic.
Let me elaborate on this. If you have method getPostsFromDatabase than you can explicitly specify in this method exact criteria which posts you want to show — for example only active, only newer than one week, etc. Query criteria is than, an example of business logic.
On the other hand, as you already mentioned, if we have to execute a database call from two different places, it has to go to a separate class.
I believe that keeping database calls in controllers are evil, no matter do we using it in some other places. What do you think about that?