7 Laravel Best Practices Worth Knowing-Laravel-php.cn

7 Laravel Best Practices Worth Knowing

青灯夜游

Release： 2023-01-03 20:24:46

Original

1659 people have browsed it

7 Laravel Best Practices Worth Knowing

Every web developer has his or her own style when writing code. At the same time, if we use the Laravel framework, everything is ready, but often we misuse the terminology here. It's not a big deal when it comes to different styles, but we have to make sure that our code follows good style. This means our code must be extensible, maintainable and testable. [Related recommendations: laravel video tutorial]

What makes our code bad or good? Because PHP is an object-oriented language, we should follow object-oriented principles, such as SOLID design principles, and consider using object-oriented mechanisms, such as inheritance, abstraction, etc. Additionally, Laravel has a large community and sometimes there are some community-created conventions. Therefore, other laravel developers who follow these conventions are able to understand our code better and faster. In this article, I will show you 7 best practices on Laravel based on object-oriented principles and some Laravel community conventions.

1. Fat model, thin controller

If we have a very complex query builder or raw SQL statement, we should move this query to the model or In the warehouse.

Bad:

<?php
public function index()
{
    $partners = Partner::where(&#39;email_verified_at&#39;, &#39;!=&#39;, null)
        ->with([&#39;products&#39; => function ($q) {
            $q->whereDate(&#39;created_at&#39;, now());
        }])
        ->get();

    return view(&#39;index&#39;, [&#39;partners&#39; => $partners]);
}

Copy after login

Good:

<?php
public function index()
{
    return view(&#39;index&#39;, [&#39;partners&#39; => $this->partner->newProducts()]);
}

class Partner extends Model
{
    public function newProducts()
    {
        return $this->where(&#39;email_verified_at&#39;, &#39;!=&#39;, null)
            ->with([&#39;products&#39; => function ($q) {
                $q->whereDate(&#39;created_at&#39;, now());
            }])
            ->get();
    }
}

Copy after login

2. The business logic in the service class

is the same as the first one above Point related, we should have a thin controller and then we should move all business logic into separate service classes. So the controller should have only one responsibility and hopefully we can reuse this service in other controllers.

Bad:

<?php
public function store(Request $request)
{
    $user = User::create();

    $user->update([&#39;last_login&#39; => now()]);

    dispatch(new UserCreated($user));

    // ...
}

Copy after login

Good:

<?php
public function store(Request $request)
{
    $this->userService->create($request);

    ....
}

class UserService
{
    public function create($request)
    {
       // ...
    }
}

Copy after login

3.Eloquent queries are better than native SQL statements.

Using Eloquent for queries is more readable, avoids SQL injection, and is easier to maintain.

Bad:

<?php
SELECT *
FROM `articles`
WHERE EXISTS (SELECT *
              FROM `users`
              WHERE `articles`.`user_id` = `users`.`id`
              AND EXISTS (SELECT *
                          FROM `profiles`
                          WHERE `profiles`.`user_id` = `users`.`id`) 
              AND `users`.`deleted_at` IS NULL)
AND `verified` = &#39;1&#39;
AND `active` = &#39;1&#39;
ORDER BY `created_at` DESC

Copy after login

Good:

<?php
Article::has(&#39;user.profile&#39;)->verified()->latest()->get();

Copy after login

4.DRY (Don't Repeat Yourself)

We should Consider moving reusable logic/component parts to separate places.
In the blade template, we can use components to reuse the front-end part. In the server, we can move the logic to a separate service class, Eloquent scope, or even create our own package.

<!DOCTYPE html>
<html>
<head>
<title>DRY</title>
</head>
<body>

<h1>Custom Calendar</h1>

<x-custom-calendar>

</body>
</html>

Copy after login

5. Do not execute queries in Blade templates

Although it is possible to execute queries in Blade templates, it is best not to do so.

bad. Will cause N 1 problem.

@foreach (User::all() as $user)
    {{ $user->email }}
@endforeach

Copy after login

Okay:

$users = User::all(); // Server Query
@foreach ($users as $user)
    {{ $user->email }}
@endforeach

Copy after login

6. Using database transactions

If we have some complex and lengthy logic/queries, then we should consider Use database transactions. By using this feature, we can easily roll back the database if needed to ensure that our data is not saved to the database, so we are confident that our data is reliable.

<?php
public function store(Request $request)
{
    DB::beginTransaction();
    $user = User::create();
    $response = app(&#39;service&#39;)->create($user);

    if (!$response) {
      DB::rollback();
      return;
    }
    // ...
    DB::commit();
 }

Copy after login

7. Don’t hardcode text

We should not hardcode any text in code/controller. This makes it easy to maintain and extend in the future. If we want to display a message to the user we can use translations, constants in models/classes to set any value or config files to save our configuration.

trans(&#39;user.created&#39;); // &#39;User Successfully Created&#39;
$types = Product::TYPES; // Const in a Class/Model

Copy after login

Original address: https://cerwyn.medium.com/7-best-practices-in-laravel-you-should-know-2ed9878293de

Translation address: https ://learnku.com/laravel/t/67021

For more programming-related knowledge, please visit: programming video! !

The above is the detailed content of 7 Laravel Best Practices Worth Knowing. For more information, please follow other related articles on the PHP Chinese website!