5 of the Common Mistakes Made by Laravel Programmers
During the experience which we gain from the recruitment processes at Devpark, we learned that there are few common mistakes which we meet with many of our candidates in the Laravel 5 code. In the below article we will try to point those common mistakes and give some advice how it should be done in the right way. We will just point to the better way – there are many articles out there which describe how to do it, so with this article you should know what to search for.
#1 Validation in the Controllers
Many times we see, that the request params validation is made in the controller method. Since it was acceptable in the Laravel 4, it is not the proper way in the Laravel 5 which income with FormRequest feature, which is a proper place to validate requests at least by using the rules() method.
About more details how to use it and made the validation outside of the controllers, please follow with this link:
#2 Fat Controller
One of the most important mistakes is placing the business logic inside of the controller methods. Probably – this is affected by the leak in knowledge and experience. So that the programmer doesn’t know how to deal with the code, which do not fit to the Eloquent model class. So – he place it in the controller.
There are many architecture patterns how to deal with that. During the last days, a very popular in the Laravel world, has become the Repositories. But – you should know what you are doing when you want to use it. In our opinion, if you don’t plane to change the db engine or move your code to other framework – there is no reason to go this path. At Devpark we have other way called Managers class which impements the Facade pattern.
So the code, which is not responsible to access and put/get/edit the database is placed at the Manager methods. Of course you should read also how to write SOLID code, to better understand how to create proper Managers too. Anyway – thanks to that, the controller methods simplify just to call the manager metod and return the results e.g. with the proper view file or JSON response. At Devpark, we decide that we will place the Mangers files inside the Service directory
Below you can find an example of the controller method after refactorization. The business logic has been moved into the managers. before that it takes above 200 lines of code and was very unreadable. It was a nightmare to figure our which part of code is responsible for which logic.
Also below you can find an example of one ot the methods called in the controller above. As you can notice there, the code has also separated functions which are responsible for specified part of the logic. Don’t you think that it is quite readable now, even if you don’t know the application ?
It’s quite bad if you will have to place the php code directly in the view fiels to get or operate on some data. An example of this can be the logged user avatar displaying in the common part of the views which e.g. top navigation in layout. There is a feature which allows to do it in the proper way called ViewComposer. You should place those kind of code inside it to initialize the variable, and later just display it in the view file.More about how to use is you can find directly in the Laravel documentation:
Using the Laravel Facades inside of the controllers & middleware in Laravel is reasonable, since those are strictly related with Laravel framework. But you should never use it outside of controllers and middleware. Instead – the Dependency Injection should be used. It will helps in many parts like: having the code under control, make the code scalable, it will be much easier to write code tests and to understand the code.p.s. The Laravel Facades are becomes strictly from the Laravel framework and it is important to understand that they are not the same as facade design pattern!! (and also they are not static methods usage!)