Home>Article>PHP Framework> 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.
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:
with(['products' => function ($q) { $q->whereDate('created_at', now()); }]) ->get(); return view('index', ['partners' => $partners]); }
Good:
$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(); } }
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:
update(['last_login' => now()]); dispatch(new UserCreated($user)); // ... }
Good:
userService->create($request); .... } class UserService { public function create($request) { // ... } }
Using Eloquent for queries is more readable, avoids SQL injection, and is easier to maintain.
Bad:
Good:
verified()->latest()->get();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.DRY Custom Calendar
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 }} @endforeachOkay:
$users = User::all(); // Server Query @foreach ($users as $user) {{ $user->email }} @endforeach6. 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.
create($user); if (!$response) { DB::rollback(); return; } // ... DB::commit(); }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('user.created'); // 'User Successfully Created' $types = Product::TYPES; // Const in a Class/ModelOriginal 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!