How to properly organize application logic in Laravel?

Question

Laravel

Hello!
I’m immersing myself in the world of Laravel a little, and I have a question: how to organize the application logic?
A little more detail:
there is an ArticleController controller,
there is a Models\Article Model
and a repository Repositories\ArticleRepository
In addition, there are categories of articles for which a separate model, a separate repository.
We take the show controller's show method, to view a specific article
in it, we access the repository and get our article or 404 we pass to the view I
want to add some logic and data transformation:
1) convert the date to the desired format
2) increase the number of views
3) get a separate number of likes and dislikes (they are stored in the same table
)
dislikes.
The question is how then to transfer this data to the view, as a separate array or modify the model.
Probably, with an array of modified data, this is complete nonsense, because if it is not viewing an article, but displaying a list, then you will get porridge.
In general, I would like to hear / see how someone does on real projects

Answer 1

we get our article or 404 and pass it to view

Article or exception. Not a 404. Apart from the controller, no one in the application knows that you are working with HTTP.
Convert the date to Carbon/DateTime in the controller - the service/repository should already have an object in UTC.
Increase views with a service in the controller.
Get likes and dislikes with a model scope that does withCount under the hood.
In view in this case, you do not need to give any extra. data except for the Article itself, but if it's impatient - pass it as separate parameters.
There shouldn't be any magic arrays. Everything beyond the controller (inclusive) should replace incomprehensible arrays with DTOs (google, there is a ready-made implementation from spatie, for example), because arrays are not typed, it is not clear what keys are there, when they can be, where this array came from and so further - dto solves these problems.
If you really feel like it, you can move all the above logic from the controller into a separate class - it can be convenient to fix something quickly or simulate someone's action, but these are rare cases.

Answer 2

Yes, yes, 99% of hamsters make a Repository without even understanding why, and only a database and eloquent as a data source ...
Yes, it’s right to make a Service for logic. and DTO to pass complex data to Service.
You pass whatever you want to the view, because the data for the view is prepared by the controller as you want.
On real projects, horses are driven and 99% of the logic, hell knows where and how, everything is transmitted through the stump of the deck :)
Business does not like to pay for beautiful architecture because it takes 3 times longer and rarely shoots in the future.
Yes, there are places where it will save time, but often it is an overhead.
But it is better to introduce a minimum Service layer.
Another thing is that if you enter it incorrectly !!! and often it happens if you are not a signor or an architect, and then these crooked services interfere, not help. But the attempt is not torture, especially if the customer is ready to pay you 5 times more than if they wrote on models ...
Yes, yes, everything is bad.