Laravel by design is a very easy web application development framework. It is by design very easy to start, to get going and starting to scaffold application. It is this simplicity that sometimes leaves developer on how to implement some harder than common features. From experience, these are the dos and don'ts that will save you a lot of time and in turn assist you in writing better efficient web applications.

Don’t —  write database logic in view or controller

Sometimes you may find some functionalities require you to write a bit complicated database logic. With Laravel being an MVC framework, the options are very few out of the box. This is were you have to get a bit creative. The database logic shouldn't be written in the model either, model is only for describing the database. This were the Repository and Service can come in handy.

Do — use resource controllers for CRUD operations

At first the resource controllers may not be a very good idea, or they may seem like a lot of work, but they are actually the one thing that make development easier. For the common create, read, update and delete applications, use the Laravel Resource Controllers.

Don’t — use a controller for more than one feature

Make your controllers as specific as possible. And make sure you use each controller per feature. Sometimes each model should have a corresponding controller. The benefit is that your controllers will remain very thin, and make debugging, maintenance and refactoring very easy later on.

Do — use events for logic that is not directly relevant to features

For logic that is directly correlated with the controller, keep it in a separate class. This in Laravel is implemented as events. Take an example, you want send your users a welcome email every time someone signs up. You can keep the user creation logic inside the controller then trigger an event that will handle that logic.


namespace App\Http\Controllers;

use App\Http\Controller\Controller;
use Illuminate\Http\Request;
use App\User;

class RegistrationController extends Controller{
	public function register(Request $request){
		return redirect()->back();

Don’t — use Auth facade in controller constructor

Learned this the hard way. All the controllers are resolved before the user is derived from the session. The session middlewares that add the current user session to the auth object that is available inside the Auth facade, auth() helper, and request()/$request objects is run after all the controllers have been resolved from the service container. Hence if you try to access the Auth object inside the controller constructor the result will always be null.

Sometimes you may want to perform route related logic in your applications, in these times you may tempted to write the logic inside the controller or routes/web.php. This logic is very safe if you create a middleware for it. And then register the middleware. This ensures that whatever the logic, it will be run before the controller is reached.

Don’t — directly manipulate the database, always use migrations

This is basic Laravel principle. Do not do any database manipulations, or schema changes directly. Always do so using migrations. This makes deployment very easy and at any moment you can reset the database to the current state without any difficulty.

Do — use seeders and factories to populate testing/development data in database

Similar to the previous point, always use the database seeders in your tests. This gives you control over which data to be used during testing, allows data to be generated by single command, and makes the tests themselves easily reproducible once someone has downloaded the source code. Makes the project self contained.

Don’t — write validation logic inside controller use form requests.

For simple applications, you can write the validation logic inside the controller, but as the app scales and more features are required it will become more difficult to maintain and refactor the code.

See the tutorial on using form requests.

Do — always extract components from your blade views

Laravel is made to use components out of the box. This will allow you to avoid repetition of your code. For example, instead of writing header and footer on each html file, you can just create component once and reuse the component in every file.