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:
#4 Javascript and Styles inside of the ‚/public’ Directory
If you would like to make the live difficult to other programmers, put your Javascripts and styles inside of the /public directory.. and put each in one file ? For sure others will have to made a lot of efforts to change something…. But if you would like to do it the right way – then for sure you should split those scripts into smaller files, with adequate names and place them inside /resources/assets/ js or sass directory. With Laravel 5 you have out of the box the GULP integrated. Thanks that, you can easily sprint and manage the code. With sass your styles will be well organized, Bower will help you to add required libraries and GULP will help you to put this inside the /public in the way, that will be efficient for the browsers to download it. There are many wizards created, which describes this and you should read more about but for the beggining maybe this article wil be valuable to start with:
run-gulp-tasks-in-laravel-easily-with-elixir
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!)
