7 个值得了解的 Laravel 最佳实践

7 个值得了解的 Laravel 最佳实践

每个 web 开发人员在写代码时都有自己的风格。与此同时,如果我们使用 laravel 框架,一切都准备就绪,但通常我们在这里误用了术语。 涉及不同的风格问题不大,但我们必须确保我们的代码遵循良好的风格。这意味着我们的代码必须可扩展,可维护和可测试。【相关推荐:laravel视频教程

是什么让我们的代码变得糟糕或者良好?因为php是一种面向对象的语言,我们应该遵循面向对象的原则,如 SOLID 设计原则,并考虑使用面向对象机制,如继承,抽象等。此外,Laravel有一个大社区,有时会有一些社区创造的约定。因此,其他遵循这些约定的 laravel 开发人员能够更好地、更快地理解我们的代码。在本文中,我将根据面向对象原则和一些 Laravel 社区约定,在 Laravel 上向你展示7个最佳实践。

1.胖模型,瘦控制器

如果我们有一个非常复杂的查询构造器或原始 sql语句,我们应该将此查询移动到模型或仓库中。

坏的:

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

好的:

<?php public function index() {     return view(&#39;index&#39;, [&#39;partners&#39; => $this-&gt;partner-&gt;newProducts()]); }  class Partner extends Model {     public function newProducts()     {         return $this-&gt;where('email_verified_at', '!=', null)             -&gt;with(['products' =&gt; function ($q) {                 $q-&gt;whereDate('created_at', now());             }])             -&gt;get();     } }

2.服务类中的业务逻辑

与上述第一点相关,我们应该有一个瘦控制器,然后我们应该将所有业务逻辑移动到单独的服务类中。 所以控制器应该只有一个职责,希望我们可以在其他控制器中重用这个服务。

坏的:

<?php public function store(Request $request) {     $user = User::create();      $user->update(['last_login' =&gt; now()]);      dispatch(new UserCreated($user));      // ... }

好的:

<?php public function store(Request $request) {     $this->userService-&gt;create($request);      .... }  class UserService {     public function create($request)     {        // ...     } }

3.Eloquent 查询优于原生 SQL 语句。

使用 Eloquent 进行查询更具可读性,避免 SQL 注入,并且易于维护。

坏的:

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

好的:

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

4.DRY (Don’t Repeat Yourself)

我们应该考虑将可重用的逻辑/组件部分移动到单独的地方。
在 blade 模板中,我们可以使用组件来重用前端部分。在服务器中,我们可以将逻辑移动到一个单独的服务类、Eloquent scope作用域,甚至可以创建我们自己的包。

nbsp;html&gt;   <title>DRY</title><h1>Custom Calendar</h1>  <x-custom-calendar></x-custom-calendar>

5.不要在 Blade 模板中执行查询

尽管在 blade 模板中执行查询是可行的, 但最好不要这么做。

坏的。 将会造成 N+1 问题。

@foreach (User::all() as $user)     {{ $user-&gt;email }} @endforeach

好的:

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

6.使用数据库事务

如果我们有一些复杂而冗长的逻辑/查询,那么我们应该考虑使用数据库事务。通过使用此功能,我们可以在需要时轻松回滚数据库,以确保我们的数据不会保存到数据库中,因此我们确信我们的数据是可靠的。

<?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.不要硬编码文本

我们不应该在代码/控制器中硬编码任何文本。这样以后很容易维护和扩展。如果我们想向用户显示消息,我们可以使用翻译,模型/类中的常量来设置任何值或配置文件来保存我们的配置。

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

原文地址:https://cerwyn.medium.com/7-best-practices-in-laravel-you-should-know-2ed9878293de译文地址:https://learnku.com/laravel/t/67021

更多编程相关知识,请访问:laravel视频教程!!

© 版权声明
THE END
喜欢就支持一下吧
点赞9 分享