Jeder Webentwickler hat beim Schreiben von Code seinen eigenen Stil. Wenn wir gleichzeitig das Laravel-Framework verwenden, ist alles bereit, aber oft missbrauchen wir hier die Terminologie. Es ist keine große Sache, wenn es um verschiedene Stile geht, aber wir müssen sicherstellen, dass unser Code einem guten Stil folgt. Das bedeutet, dass unser Code erweiterbar, wartbar und testbar sein muss. [Verwandte Empfehlungen: Laravel-Video-Tutorial]
Was macht unseren Code schlecht oder gut? Da PHP eine objektorientierte Sprache ist, sollten wir objektorientierte Prinzipien wie die SOLID-Designprinzipien befolgen und die Verwendung objektorientierter Mechanismen wie Vererbung, Abstraktion usw. in Betracht ziehen. Darüber hinaus hat Laravel eine große Community und manchmal gibt es einige von der Community erstellte Konventionen. Daher können andere Laravel-Entwickler, die diese Konventionen befolgen, unseren Code besser und schneller verstehen. In diesem Artikel zeige ich Ihnen 7 Best Practices für Laravel, die auf objektorientierten Prinzipien und einigen Konventionen der Laravel-Community basieren.
Wenn wir einen sehr komplexen Abfrage-Builder oder eine unformatierte SQL-Anweisung haben, sollten wir diese Abfrage in ein Modell oder Warehouse verschieben.
Schlecht:
<?php
public function index()
{
$partners = Partner::where('email_verified_at', '!=', null)
->with(['products' => function ($q) {
$q->whereDate('created_at', now());
}])
->get();
return view('index', ['partners' => $partners]);
}Gut:
<?php
public function index()
{
return view('index', ['partners' => $this->partner->newProducts()]);
}
class Partner extends Model
{
public function newProducts()
{
return $this->where('email_verified_at', '!=', null)
->with(['products' => function ($q) {
$q->whereDate('created_at', now());
}])
->get();
}
}Im Zusammenhang mit dem ersten Punkt oben sollten wir einen Thin Controller haben und dann die gesamte Geschäftslogik in einen separaten Service verschieben Klasse. Daher sollte der Controller nur eine Verantwortung haben und wir hoffen, dass wir diesen Dienst in anderen Controllern wiederverwenden können.
Schlecht:
<?php
public function store(Request $request)
{
$user = User::create();
$user->update(['last_login' => now()]);
dispatch(new UserCreated($user));
// ...
}Gut:
<?php
public function store(Request $request)
{
$this->userService->create($request);
....
}
class UserService
{
public function create($request)
{
// ...
}
}Die Verwendung von Eloquent für Abfragen ist besser lesbar, vermeidet SQL-Injection und ist einfach zu warten.
Schlecht:
<?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` = '1'
AND `active` = '1'
ORDER BY `created_at` DESCGut:
<?php Article::has('user.profile')->verified()->latest()->get();
Wir sollten erwägen, die wiederverwendbaren Logik-/Komponententeile an einen separaten Ort zu verschieben.
In Blade-Vorlagen können wir Komponenten verwenden, um Front-End-Teile wiederzuverwenden. Auf dem Server können wir die Logik in eine separate Serviceklasse, den Eloquent-Bereich, verschieben oder sogar unser eigenes Paket erstellen.
<!DOCTYPE html> <html> <head> <title>DRY</title> </head> <body> <h1>Custom Calendar</h1> <x-custom-calendar> </body> </html>
Obwohl das Ausführen von Abfragen in Blade-Vorlagen möglich ist, sollten Sie dies lieber nicht tun.
Schlecht. Wird ein N+1-Problem verursachen.
@foreach (User::all() as $user)
{{ $user->email }}
@endforeachOkay:
$users = User::all(); // Server Query
@foreach ($users as $user)
{{ $user->email }}
@endforeachWenn wir komplexe und langwierige Logik/Abfragen haben, sollten wir die Verwendung von Datenbanktransaktionen in Betracht ziehen. Mithilfe dieser Funktion können wir die Datenbank bei Bedarf problemlos zurücksetzen, um sicherzustellen, dass unsere Daten nicht in der Datenbank gespeichert werden, sodass wir sicher sein können, dass unsere Daten zuverlässig sind.
<?php
public function store(Request $request)
{
DB::beginTransaction();
$user = User::create();
$response = app('service')->create($user);
if (!$response) {
DB::rollback();
return;
}
// ...
DB::commit();
}Wir sollten keinen Text im Code/Controller fest codieren. Dies erleichtert die Wartung und Erweiterung in der Zukunft. Wenn wir dem Benutzer eine Nachricht anzeigen möchten, können wir Übersetzungen, Konstanten in Modellen/Klassen zum Festlegen beliebiger Werte oder Konfigurationsdateien zum Speichern unserer Konfiguration verwenden.
trans('user.created'); // 'User Successfully Created' $types = Product::TYPES; // Const in a Class/Model
Originaladresse: https://cerwyn.medium.com/7-best-practices-in-laravel-you-should-know-2ed9878293de
Übersetzungsadresse: https://learnku.com/laravel/t /67021
Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Programmiervideo! !
Das obige ist der detaillierte Inhalt von7 wissenswerte Laravel Best Practices. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
So öffnen Sie eine PHP-Datei
So entfernen Sie die ersten paar Elemente eines Arrays in PHP
Was tun, wenn die PHP-Deserialisierung fehlschlägt?
So verbinden Sie PHP mit der MSSQL-Datenbank
So verbinden Sie PHP mit der MSSQL-Datenbank
So laden Sie HTML hoch
So lösen Sie verstümmelte Zeichen in PHP
So öffnen Sie PHP-Dateien auf einem Mobiltelefon
