Laravel模型获取器？获取器怎样定义使用？
|
6
|
php框架

2777 字
|
11 分钟

Laravel模型获取器用于在读取属性时动态格式化数据，如拼接姓名、格式化日期等，通过get{AttributeName}Attribute方法实现，配合$appends可自动包含在JSON输出中，需避免N+1查询和复杂逻辑以保证性能。

Laravel模型获取器？获取器怎样定义使用？

Laravel模型获取器（Accessors）是框架提供的一种机制，用于在从数据库获取模型属性时，对这些属性进行自动转换或格式化。简单来说，它们允许你在不改变数据库实际存储值的情况下，动态地修改属性的呈现方式。定义获取器通常通过在模型中创建特定命名格式的方法来实现，使用时就像访问模型的普通属性一样。

解决方案

Laravel模型获取器本质上是模型类中的特殊方法，它们在你尝试访问某个属性时被自动调用。这种机制非常灵活，可以用于多种场景，比如格式化日期、拼接字符串、计算派生属性，甚至是进行简单的加密或解密操作（尽管对于敏感数据，更推荐使用专门的加密服务）。

要定义一个获取器，你需要在你的模型中创建一个方法，遵循 

get{AttributeName}Attribute

的命名约定。其中，

{AttributeName}

是你想要转换的属性的“驼峰式”命名版本。例如，如果你有一个 

first_name

和 

last_name

字段，你可能想要一个 

full_name

获取器来将它们拼接起来。

这个方法会接收原始属性值作为参数（如果存在），并返回你希望最终呈现的值。当你在模型实例上访问 

full_name

属性时，Laravel就会自动调用 

getFullNameAttribute

方法，并返回它的结果。

举个例子：

<?php  namespace AppModels;  use IlluminateDatabaseEloquentModel;  class User extends Model {     /**      * 获取用户的全名。      *      * @return string      */     public function getFullNameAttribute()     {         // 这里可以加入一些业务逻辑，比如判断first_name或last_name是否为空         // 避免直接拼接可能导致多余空格的情况。         $firstName = $this->attributes['first_name'] ?? '';         $lastName = $this->attributes['last_name'] ?? '';          if (empty($firstName) && empty($lastName)) {             return '匿名用户';         } elseif (empty($firstName)) {             return $lastName;         } elseif (empty($lastName)) {             return $firstName;         }          return "{$firstName} {$lastName}";     }      /**      * 获取用户是否是管理员。      * 假设数据库中有一个 `is_admin` 字段存储 0 或 1。      *      * @return bool      */     public function getIsAdminAttribute()     {         return (bool) $this->attributes['is_admin'];     }      /**      * 获取格式化后的创建日期。      *      * @return string      */     public function getCreatedAtFormattedAttribute()     {         // 确保 created_at 是 Carbon 实例，Laravel默认会做这个转换         return $this->created_at ? $this->created_at->format('Y年m月d日 H:i') : 'N/A';     } }

定义好获取器后，你就可以像访问普通模型属性一样使用它们了：

$user = User::find(1);  echo $user->full_name; // 会调用 getFullNameAttribute() echo $user->is_admin;  // 会调用 getIsAdminAttribute() echo $user->created_at_formatted; // 会调用 getCreatedAtFormattedAttribute()

这种方式让模型变得更加“智能”，它能根据业务需求，在数据离开模型时提供更友好的格式，而不需要在控制器或视图层重复处理这些格式化逻辑。

Laravel模型获取器与修改器的区别是什么？

谈到Laravel模型的属性转换，除了获取器（Accessors），我们通常还会提到修改器（Mutators）。这两者其实是相辅相成的，但作用的方向截然不同，理解它们的区别对于合理组织代码非常关键。

简单来说，获取器是在你从模型中“取出”数据时进行转换的。它就像一个过滤器，在你读取 

Model->attribute

的时候，悄悄地把原始数据处理一番，再给你看处理后的结果。它的目的是为了数据的展示或计算，不会影响数据库中实际存储的值。比如，你可能有一个 

price

字段存储的是分，但你希望在显示时自动转换成元。

而修改器则是在你往模型中“存入”数据时进行转换的。当你设置 

Model->attribute = $value

时，修改器会介入，对 

$value

进行预处理，然后才将处理后的值写入模型的 

attributes

数组，最终保存到数据库。它的目的是为了数据的存储规范化、加密或者其他入库前的处理。比如，你可能希望用户输入的密码在保存前自动进行哈希加密。

让我们通过代码对比一下：

获取器示例 (Accessor):

// 在 User 模型中 public function getEmailDomainAttribute() {     // 假设 email 字段是 'john.doe@example.com'     return explode('@', $this->attributes['email'])[1] ?? null; }  // 使用时 $user = User::find(1); echo $user->email_domain; // 输出 'example.com'

这里，

email_domain

并不是数据库中的一个字段，而是根据 

email

字段动态计算出来的。

修改器示例 (Mutator):

// 在 User 模型中 public function setPasswordAttribute($value) {     // 在保存密码前自动进行哈希加密     $this->attributes['password'] = bcrypt($value); }  // 使用时 $user = new User; $user->password = 'secret'; // 调用 setPasswordAttribute()，实际存入的是哈希值 $user->save();

这里，当你给 

password

属性赋值时，修改器会自动将其加密后再存储，确保数据库中不会明文保存密码。

总结一下，获取器是“读时转换”，修改器是“写时转换”。它们共同构成了Laravel模型属性处理的强大工具集，帮助开发者在数据进出数据库时保持一致性和业务逻辑的封装。选择哪一个取决于你的需求是处理数据展示，还是处理数据存储。

如何让模型获取器自动包含在JSON或数组输出中？

在构建API或需要将模型实例转换为JSON或数组格式时，一个常见需求是希望自定义的获取器也能被自动包含进去。默认情况下，当你调用 

$model->toArray()

或 

$model->toJson()

方法时，只有那些对应数据库列的属性才会被包含。但Laravel提供了一个非常简洁的方式来解决这个问题，那就是使用模型中的 

$appends

属性。

$appends

属性是一个数组，你可以在其中列出所有你希望在模型转换为数组或JSON时自动附加的获取器名称。这些名称应该与你定义的获取器方法名中的“属性名”部分一致，也就是 

get{AttributeName}Attribute

中的 

{AttributeName}

的小写蛇形命名。

Laravel模型获取器？获取器怎样定义使用？

Writer

企业级AI内容创作工具

Laravel模型获取器？获取器怎样定义使用？131

查看详情 Laravel模型获取器？获取器怎样定义使用？

举个例子，继续使用我们之前的 

User

模型，它定义了 

full_name

和 

is_admin

获取器：

<?php  namespace AppModels;  use IlluminateDatabaseEloquentModel;  class User extends Model {     // ... 其他属性和方法 ...      /**      * 声明哪些获取器应该在模型转换为数组或 JSON 时自动附加。      *      * @var array      */     protected $appends = ['full_name', 'is_admin'];      /**      * 获取用户的全名。      *      * @return string      */     public function getFullNameAttribute()     {         return "{$this->first_name} {$this->last_name}";     }      /**      * 获取用户是否是管理员。      *      * @return bool      */     public function getIsAdminAttribute()     {         return (bool) $this->is_admin; // 假设 is_admin 是数据库字段     } }

现在，当你获取一个 

User

模型实例并将其转换为数组或JSON时，

full_name

和 

is_admin

这两个获取器的值就会自动包含在输出中：

$user = User::find(1);  // 转换为数组 $userData = $user->toArray(); /* $userData 会类似这样： [     'id' => 1,     'first_name' => 'John',     'last_name' => 'Doe',     'email' => 'john.doe@example.com',     'full_name' => 'John Doe', // 自动包含了！     'is_admin' => true,        // 自动包含了！     // ... 其他数据库字段 ] */  // 转换为 JSON 字符串 $userJson = $user->toJson(); // 同样，JSON 字符串中也会包含 full_name 和 is_admin 字段

需要注意的是，

$appends

属性中的名称必须与获取器方法名中的属性部分（小写蛇形）严格对应。如果你的获取器执行了复杂的计算或数据库查询，将其添加到 

$appends

可能会在大量模型实例被序列化时引入性能问题（例如，N+1 查询）。在这种情况下，你可能需要仔细权衡，或者只在特定需要时手动附加这些属性，而不是全局使用 

$appends

。

定义获取器时有哪些常见的陷阱或最佳实践？

虽然Laravel获取器非常强大且方便，但在实际使用中，如果不注意一些细节，也可能会遇到一些问题或导致代码质量下降。以下是一些常见的陷阱和推荐的最佳实践：

常见陷阱：

  1. 在获取器中执行数据库查询 (N+1问题): 这是最常见的性能陷阱。如果你的获取器内部执行了新的数据库查询来获取相关数据，并且这个模型实例被批量加载（例如，

    User::all()

    ），那么每次访问这个获取器都会触发一次额外的查询。这会导致臭名昭1的N+1问题，严重拖慢应用速度。

    • 示例： 
      getUserOrdersCountAttribute()

      在其中 

      return $this->orders()->count();
    • 后果： 如果加载100个用户，就会有101次数据库查询（1次加载用户，100次加载订单数量）。

  2. 获取器逻辑过于复杂或执行耗时操作: 获取器应该尽量保持轻量和快速。如果你的获取器需要进行大量计算、外部API调用或复杂的数据处理，那么它可能会阻塞请求，影响用户体验。

    • 示例： 在获取器中调用第三方服务，或者进行复杂的图像处理。

  3. 命名冲突: 确保你的获取器名称（

    {AttributeName}

    部分）不会与模型中已有的数据库字段名、关系方法名或模型自带的魔术方法名冲突。否则，可能会导致意料之外的行为。

  4. 过度使用 

    $appends

    : 尽管 

    $appends

    很方便，但如果你将所有获取器都添加到 

    $appends

    中，即使在不需要这些数据的情况下，它们也会被计算并包含在JSON/数组输出中。这可能会增加不必要的处理开销和数据传输量，尤其是在大型数据集中。

最佳实践：

  1. 保持获取器简洁和专注: 获取器最适合用于数据的格式化、简单的派生值计算或布尔类型转换。如果逻辑变得复杂，考虑将其提取到模型中的私有方法、专用的服务类或观察者中。

  2. 利用 Eager Loading (预加载) 解决 N+1 问题: 如果获取器需要依赖关联数据，请确保在使用模型时通过 

    with()

    方法进行预加载。这样，所有相关数据都会在一次查询中加载，避免了获取器内部的重复查询。

    • 示例： 
      User::with('orders')->get();

      然后在 

      getUserOrdersCountAttribute()

      中直接访问已加载的 

      orders

      关系。

  3. 缓存昂贵的计算结果: 对于那些计算成本较高但结果不经常变化的获取器，考虑在模型实例的生命周期内缓存其结果。

    • 示例： 
      public function getComplexCalculationResultAttribute() {     if (! isset($this->attributes['cached_complex_result'])) {         // 执行耗时计算         $result = $this->performHeavyCalculation();         $this->attributes['cached_complex_result'] = $result;     }     return $this->attributes['cached_complex_result']; }

      当然，更完善的缓存策略可能涉及 Laravel 的缓存系统。

  4. 区分展示逻辑与业务逻辑: 获取器主要用于展示层的数据准备。核心业务逻辑或会改变模型状态的操作不应该放在获取器中。这些应该放在模型方法、服务或控制器中。

  5. 合理使用 

    $appends

    : 只有那些在绝大多数API响应或数据传输中都需要的获取器才应该添加到 

    $appends

    。对于不常用的获取器，可以在需要时手动访问，或者在控制器中根据需要选择性地附加。

遵循这些原则，可以帮助你充分发挥Laravel获取器的优势，同时避免潜在的性能和维护问题，让你的代码更加健壮和高效。

以上就是Laravel模型获取器？获取器怎样定义使用？的详细内容，更多请关注php word laravel js json app access 工具 ai 区别 敏感数据 api调用 laravel json count 封装 字符串 布尔类型 Attribute Accessors 类型转换 this 数据库

php word laravel js json app access 工具 ai 区别 敏感数据 api调用 laravel json count 封装 字符串 布尔类型 Attribute Accessors 类型转换 this 数据库

app
上一篇
下一篇

推荐文章

安全显示查询参数值的静态页面搭建指南
安全显示查询参数：简易静态页面实现指南
Composer如何自定义命令
VSCode的配置文件（JSON）如何灵活管理不同工作区？
币安APP安卓版下载 币安交易所iOS官方v3.3.8最新版
如何在Linux中开机自启 Linux systemctl enable配置
如何彻底卸载composer
thinkphp Cookie读写操作失败怎么办
VSCode故障排除怎么启动_VSCode故障排除模式启动
什么是以太坊ETH？新手如何才能获得以太坊？