Laravel Best Practices

By SomeOne
12 months Ago

1.Single responsibility principle

A class and a method should have only one responsibility.

Bad:

public function getFullNameAttribute(): string
{
    if (auth()->user() && auth()->user()->hasRole('client') && auth()->user()->isVerified()) {
        return 'Mr. ' . $this->first_name . ' ' . $this->middle_name . ' ' . $this->last_name;
    } else {
        return $this->first_name[0] . '. ' . $this->last_name;
    }
}

Good:

public function getFullNameAttribute(): string
{
    return $this->isVerifiedClient() ? $this->getFullNameLong() : $this->getFullNameShort();
}

public function isVerifiedClient(): bool
{
    return auth()->user() && auth()->user()->hasRole('client') && auth()->user()->isVerified();
}

public function getFullNameLong(): string
{
    return 'Mr. ' . $this->first_name . ' ' . $this->middle_name . ' ' . $this->last_name;
}

public function getFullNameShort(): string
{
    return $this->first_name[0] . '. ' . $this->last_name;
}

2.Fat models, skinny controllers

Put all DB related logic into Eloquent models.
แยกส่วนการทำงาน DB ไว้ที่ Model แล้วไปเรียกใช้ที่ controller

Bad: ใส่ทั้งหมดไว้ที่ controller

public function index()
{
    $clients = Client::verified()
        ->with(['orders' => function ($q) {
            $q->where('created_at', '>', Carbon::today()->subWeek());
        }])
        ->get();

    return view('index', ['clients' => $clients]);
}

Good: ดึงข้อมูลโดยใช้ model และเรียกใช้ ด้วย controller

// controller class
public function index()
{
    return view('index', ['clients' => $this->client->getWithNewOrders()]);
}

// model class
class Client extends Model
{
    public function getWithNewOrders(): Collection
    {
        return $this->verified()
            ->with(['orders' => function ($q) {
                $q->where('created_at', '>', Carbon::today()->subWeek());
            }])
            ->get();
    }
}

3.Validation

Move validation from controllers to Request classes.
ย้ายส่วนของการ validation ไปที่ Request classes แทนการเรียกใช้ตรงๆใน controller

Bad: validation ใน controller เลย

public function store(Request $request)
{
    $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
        'publish_at' => 'nullable|date',
    ]);

    ...
}

Good: แยก validation ไปไว้ที่ Request classes เลย

// controller class
public function store(PostRequest $request)
{
    ...
}


// Request class
class PostRequest extends Request
{
    public function rules(): array
    {
        return [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
            'publish_at' => 'nullable|date',
        ];
    }
}

4.Business logic should be in service class

A controller must have only one responsibility, so move business logic from controllers to service classes.

5.Don’t repeat yourself (DRY)

Reuse code when you can. SRP is helping you to avoid duplication. Also, reuse Blade templates, use Eloquent scopes etc.

6.Prefer to use Eloquent over using Query Builder and raw SQL queries. Prefer collections over arrays

Eloquent allows you to write readable and maintainable code. Also, Eloquent has great built-in tools like soft deletes, events, scopes etc.

7.Mass assignment

8.Do not execute queries in Blade templates and use eager loading (N + 1 problem)

Bad (for 100 users, 101 DB queries will be executed):

9.Chunk data for data-heavy tasks

10.Prefer descriptive method and variable names over comments

11.Do not put JS and CSS in Blade templates and do not put any HTML in PHP classes

12.Use config and language files, constants instead of text in the code

13.Use standard Laravel tools accepted by community

Prefer to use built-in Laravel functionality and community packages instead of using 3rd party packages and tools. Any developer who will work with your app in the future will need to learn new tools. Also, chances to get help from the Laravel community are significantly lower when you’re using a 3rd party package or tool. Do not make your client pay for that.

14.Follow Laravel naming conventions

15.Use shorter and more readable syntax where possible

16.Use IoC / Service container instead of new Class

17.Do not get data from the .env file directly

18.Store dates in the standard format. Use accessors and mutators to modify date format

19.Other good practices

Avoid using patterns and tools that are alien to Laravel and similar frameworks (i.e. RoR, Django). If you like Symfony (or Spring) approach for building apps, it’s a good idea to use these frameworks instead.

Never put any logic in routes files.

Minimize usage of vanilla PHP in Blade templates.

Use in-memory DB for testing.

Do not override standard framework features to avoid problems related to updating the framework version and many other issues.

Use modern PHP syntax where possible, but don’t forget about readability.

Avoid using View Composers and similar tools unless you really know what you’re doing. In most cases, there is a better way to solve the problem.

alexeymezenin/laravel-best-practices

Categories: สัพเพเหระ