Maison > Article > cadre php > 7 meilleures pratiques Laravel à connaître

7 meilleures pratiques Laravel à connaître

青灯夜游original: 2023-01-03 20:24:461658parcourir

Chaque développeur Web a son propre style lors de l'écriture du code. En même temps, si nous utilisons le framework Laravel, tout est prêt, mais nous abusons souvent de la terminologie ici. Ce n'est pas grave lorsqu'il s'agit de styles différents, mais nous devons nous assurer que notre code suit le bon style. Cela signifie que notre code doit être extensible, maintenable et testable. [Recommandations associées : tutoriel vidéo laravel]

Qu'est-ce qui rend notre code mauvais ou bon ? Parce que PHP est un langage orienté objet, nous devons suivre les principes orientés objet, tels que les principes de conception SOLID, et envisager d'utiliser des mécanismes orientés objet, tels que l'héritage, l'abstraction, etc. De plus, Laravel possède une grande communauté et il existe parfois des conventions créées par la communauté. Par conséquent, les autres développeurs Laravel qui suivent ces conventions sont capables de comprendre notre code mieux et plus rapidement. Dans cet article, je vais vous montrer 7 bonnes pratiques sur Laravel basées sur des principes orientés objet et certaines conventions de la communauté Laravel.

1. Modèle gras, contrôleur léger

Si nous avons un générateur de requêtes très complexe ou une instruction SQL brute, nous devons déplacer cette requête vers un modèle ou un entrepôt.

Mauvais :

<?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]);
}

Bon :

<?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();
    }
}

2. Logique métier dans la classe de service

En relation avec le premier point ci-dessus, nous devrions avoir un contrôleur léger, puis nous devrions déplacer toute la logique métier dans un service séparé classe. Le contrôleur ne devrait donc avoir qu’une seule responsabilité et j’espère que nous pourrons réutiliser ce service dans d’autres contrôleurs.

Mauvais :

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

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

    dispatch(new UserCreated($user));

    // ...
}

Bon :

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

    ....
}

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

3.Les requêtes éloquentes sont meilleures que les instructions SQL natives.

L'utilisation d'Eloquent pour les requêtes est plus lisible, évite l'injection SQL et est facile à maintenir.

Mauvais :

<?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

Bon :

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

4.DRY (Ne vous répétez pas)

Nous devrions envisager de déplacer les composants logiques/composants réutilisables vers un endroit séparé.
Dans les modèles de lame, nous pouvons utiliser des composants pour réutiliser les pièces frontales. Sur le serveur, nous pouvons déplacer la logique vers une classe de service distincte, une portée Eloquent, ou même créer notre propre package.

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

<h1>Custom Calendar</h1>

<x-custom-calendar>

</body>
</html>

5. N'exécutez pas de requêtes dans les modèles Blade

Bien que l'exécution de requêtes dans les modèles Blade soit possible, il est préférable de ne pas le faire.

Mauvais. Causera un problème N+1.

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

Okay :

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

6. Utiliser les transactions de base de données

Si nous avons des logiques/requêtes complexes et longues, nous devrions alors envisager d'utiliser des transactions de base de données. En utilisant cette fonctionnalité, nous pouvons facilement restaurer la base de données si nécessaire pour garantir que nos données ne sont pas enregistrées dans la base de données, nous sommes donc sûrs que nos données sont fiables.

<?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();
 }

7. Ne codez pas en dur le texte

Nous ne devrions coder en dur aucun texte dans le code/contrôleur. Cela facilite la maintenance et l’extension à l’avenir. Si nous voulons afficher un message à l'utilisateur, nous pouvons utiliser des traductions, des constantes dans les modèles/classes pour définir n'importe quelle valeur ou des fichiers de configuration pour enregistrer notre configuration.

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

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

Adresse de traduction : https://learnku.com/laravel/t /67021

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéo de programmation ! !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

php laravel sql 常量面向对象继承对象作用域数据库 https

Déclaration：

Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn

Article précédent：Analysez quelles sont les différences entre HasOne et BelongsTo dans Laravel ?Article suivant：Analysez quelles sont les différences entre HasOne et BelongsTo dans Laravel ?

Articles Liés

Voir plus