What is your Laravel project template?

Question

Laravel

Hello.
Not the first year in web development, for the last few years I have been using Laravel (to be honest, I like it), I have read many smart books and articles. It seems that the principles of OOP are clear and all the chips with repositories and a service container in Laravel'e. And I wrote a lot of projects on it, which were easily scalable, easily introduced new features into them and changed the logic at the request of the customer. But all the same, there is always a feeling of some kind of dissatisfaction)) It seems that the template of the application itself can be even cleaner and more elegant. In this regard, two questions to find out how you solve them for yourself:
1. Controllers. Everywhere they write that the controller should contain a minimum of code, should not know how the model receives information, and how the view displays it. But how to implement it correctly within Laravel? The main difficulty in this paragraph is how to correctly pass data to the view? Those. the same controller method can output data, say, to a view template, or it can also give it to json. How to implement it correctly? I see 2 ways here:
- create some additional class (or method in the same controller) that will make the necessary request to the model. In this case, the routes refer to different methods of the controller, depending on whether you need json or view. But each of these controller methods accesses this shared method and then renders where it should.
But there seems to be a duplication going on here.
- there is only one controller method, but the GET variable "json" is used, for example. We add an if block, if the variable is present, then we return json, otherwise we return view. But also, somehow it does not look kosher ...
How to be?
2. Models. What is called models in Laravel is not suitable for the role of the business logic of the application, am I right? The models set "settings" for working with a specific database table, while you can do a lot of convenient things with relationships, make very convenient scopes. But at the same time, the model can grow even before we begin to introduce some business logic methods that are special for this particular project. Those. It is desirable to carry out logic somewhere. I often saw and did it myself, that they simply take it out to App\Services. But it is also not completely clear how to take it out correctly? Should it be independent classes that don't know anything about Eloquent (unlikely)?
But most importantly, how to be at the level of communication between models and controllers? The controller should refer to some class inside the Services, which in turn creates the necessary objects of other classes from the same Service, which in turn pull up the Laravel models ... or what? Some kind of long chain is obtained.
I read about repositories, and it seems that this can help in this matter, but I don’t fully understand how exactly? The fact that not only the database can be used as storage, but also something else is all great, of course, but I haven’t come across this much, and it seems to me that it’s redundant to take care of what can happen in one case out of a hundred. Or am I wrong, and they can be used not only to separate storage methods, but also to better organize the work of the controller with the model? Or is it not about that at all?
In general, I will be glad if you share the templates of your developments on Laravel, or give a link to the experience of other developers in this matter.
Thank you!

Answer 1

Everything is simple, for logic - services. Yes.
There are all sorts of extensions, mutators left in the models, I also put simple checks there, like checkIsPaid ()
It's okay that the service knows about the model.
And it is desirable to send data to the service through DTO, I also saw some requests are transmitted, but not by an array or a list of arguments.
The repository is usually not needed if you are using an elocuent. The repository is needed as support for various data sources. like if you have an elokuent and a docrine or just some third-party api, then the repository interface is described and implemented differently for each source.
If you only have an elocuent, then in fact the repository will repeat your model. in general sewed on soap. roughly speaking, a repository for different databases

Answer 2

- there is only one controller method, but the GET variable "json" is used, for example. We add an if block, if the variable is present, then we return json, otherwise we return view. But it doesn't look kosher either...

This is because it should be different controllers, one for the webmord, one for the API / app.

Answer 3

maybe this will help

Answer 4

I would advise you not to slow down on one Laravel, if you want a beautiful and neat code with the correct structure and principles, look towards Zend. It has a bunch of ready-to-use code, and it's very easy to extend. Everything that is possible there has an interface, that is, you need a response in json, make your own implementation using the interface, but most likely there is already a similar implementation.
Pros of zend., zend doesn’t impose anything, I don’t view the model, the most difficult thing is to master the config, if you look towards zend3, but better zend-expressive, it’s more extensible
https://olegkrivtsov.github.io/using-zend- framewor...
The book on zf3 can be skimmed over, you will understand the advantages yourself
https://github.com/zendframework/zend-expressive
Plus a bunch of reps of the code you need (100+)

Answer 5

On the first question, it is desirable to separate the controllers responsible for view and json. Ie 2 controllers are created. One returns view the other json.
On the subject of the model, an implementation option is described here .
In general, if you look at Java for comparison, there is a DTO pattern that simplifies life