Laravel의 모델 이벤트에 대한 가이드

Laravel의 모델 이벤트는 웅변 모델에서 특정 작업을 수행 할 때 로직을 자동으로 실행하는 데 도움이되는 매우 편리한 기능입니다. 그러나 부적절하게 사용하면 때때로 이상한 부작용으로 이어질 수 있습니다.

이 기사는 어떤 모델 이벤트와 Laravel 애플리케이션에서 사용하는 방법을 살펴 봅니다. 또한 모델 이벤트를 테스트하는 방법과 이벤트를 사용할 때 알리는 몇 가지 문제를 탐구 할 것입니다. 마지막으로, 사용할 수있는 이벤트를 모델링 할 수있는 몇 가지 대안을 다룹니다.

이벤트와 청취자는 무엇입니까?

당신은 "이벤트"와 "청취자"에 대해 들었을 것입니다. 그러나 당신이 그것에 대해 들어 본 적이 없다면, 여기에 대한 간단한 개요가 있습니다 :

#Event

이들은 행동하고자하는 앱에서 발생하는 일입니다. 예를 들어, 사용자는 웹 사이트에 가입하고 사용자 로그인하는 등입니다.

일반적으로 Laravel에서는 이벤트가 PHP 클래스입니다. 프레임 워크 또는 타사 패키지에서 제공하는 이벤트 외에도 일반적으로

---

디렉토리에 저장됩니다.

다음은 사용자가 웹 사이트에 등록 할 때 예약 할 수있는 간단한 이벤트 클래스의 예입니다.

위의 기본 예에는 생성자에서 모델 인스턴스를 수락하는 이벤트 클래스가 있습니다. 이 이벤트 클래스는 등록 된 사용자 인스턴스를 저장하기위한 간단한 컨테이너입니다.

파견되면 이벤트가 듣는 청취자를 트리거합니다.

다음은 사용자가 등록 할 때 이벤트를 예약하는 방법의 간단한 예입니다.

위의 예에서는 새 사용자를 생성 한 다음 사용자 인스턴스를 사용하여

이벤트를 예약합니다. 리스너가 올바르게 등록되었다고 가정하면 이벤트에서 듣는 청취자가 트리거됩니다.

#Listener 리스너는 특정 이벤트가 발생할 때 실행하려는 코드 블록입니다. app/Events 예를 들어, 사용자 등록 예제를 사용하면 사용자가 등록 할 때 사용자에게 환영 이메일을 사용자에게 보낼 수 있습니다. 이벤트에 대한 리스너를 만들고 환영 이메일을 보낼 수 있습니다.

Laravel에서 청취자는 일반적으로 디렉토리에있는 수업입니다.

사용자가 등록 할 수있을 때 사용자에게 환영 이메일을 보내는 청취자의 예 :

위의 코드 예제에서 보았 듯이,

declare(strict_types=1);

namespace App\Events;

use App\Models\User;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

final class UserRegistered
{
    use Dispatchable;
    use InteractsWithSockets;
    use SerializesModels;

    public function __construct(public User $user)
    {
        //
    }
}

리스너 클래스에는 이벤트 및 청취자에 대한보다 심층적 인 지침은 공식 문서를 확인할 수 있습니다. https://www.php.cn/link/d9a8c56824cfbe66f28f85edbbe83e09 > 모델 이벤트 란 무엇입니까?

Laravel 응용 프로그램에서는 일반적으로 특정 작업이 발생할 때 이벤트를 수동으로 예약해야합니다. 위의 예에서 보았 듯이 다음 코드를 사용하여 이벤트를 예약 할 수 있습니다. 그러나 Laravel에서 웅변 모델을 사용할 때 일부 이벤트가 자동으로 예약되므로 수동으로 예약 할 필요가 없습니다. 이벤트가 발생할 때 작업을 수행하려면 청취자를 정의하면됩니다.

다음 목록은 웅변 모델에 의해 자동으로 예약 된 이벤트와 트리거를 보여줍니다.

검색된 - 데이터베이스에서 검색합니다.

만들기 - 모델 생성.

---

생성 된 - 모델이 생성되었습니다.

업데이트 - 모델 업데이트.

업데이트 - 모델이 업데이트되었습니다.

declare(strict_types=1);

namespace App\Events;

use App\Models\User;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

final class UserRegistered
{
    use Dispatchable;
    use InteractsWithSockets;
    use SerializesModels;

    public function __construct(public User $user)
    {
        //
    }
}

저장 - 모델 생성 또는 업데이트.

저장 - 모델이 생성되거나 업데이트되었습니다.

삭제 - 모델 삭제.

삭제 - 모델이 삭제되었습니다.

쓰레기 - 모델이 부드럽게 삭제되었습니다.

강제 소속 - 모델의 강제 삭제.
• 강제로 - 모델은 삭제되도록 강요당했습니다
복원 - 소프트 삭제에서 모델 복구.
• 복원 - 모델은 소프트 삭제에서 복구되었습니다.
복제 - 모델을 복제합니다.
위 목록에서 일부 이벤트 이름이 비슷합니다. 로 끝나는 이벤트는 작업이 시작되기 전에 실행되며 변경 사항은 데이터베이스에 지속됩니다. 로 끝나는 이벤트는 작업이 발생한 후에 실행되며 변경 사항은 데이터베이스에 지속됩니다.
• Laravel 애플리케이션에서 이러한 모델 이벤트를 사용하는 방법을 살펴 보겠습니다.
• 사용
모델 이벤트 듣기 모델 이벤트를 듣는 한 가지 방법은 모델에서 속성을 ​​정의하는 것입니다.
• 이 속성을 사용하면 이벤트가 발생할 때 예약 해야하는 이벤트 클래스에 웅변 모델 이벤트를 매핑 할 수 있습니다. 즉, 다른 이벤트를 처리하는 것처럼 청취자를 정의 할 수 있습니다.
더 많은 맥락을 제공하려면 예를 살펴 보겠습니다.
• 우리가 두 가지 모델의 블로그 애플리케이션을 구축한다고 가정 해 봅시다 :
와 . 우리는 두 모델 모두 소프트 삭제를 지원한다고 말할 것입니다. 새로운 를 저장하면 내용의 길이를 기반으로 기사의 읽기 시간을 계산하려고합니다. 저자를 부드럽게 삭제하면 저자가 모든 기사를 부드럽게 삭제하기를 원합니다.
• ##모델을 세트
우리는 다음과 같이 모델을 가질 수 있습니다 :
• 위의 모델에는 다음과 같습니다
  • 는 모델 이벤트를 이벤트 클래스에 매핑하는 속성을 ​​추가했습니다. 즉, 모델이 삭제되면 새 이벤트가 예정되어 있음을 의미합니다. 나중에이 이벤트 클래스를 만들 것입니다. dispatchesEvents 관계를 정의합니다. deleted 피처를 사용하여 모델에서 소프트 삭제가 활성화됩니다. AppEventsAuthorDeleted AppEventsAuthorDeleted
  모델을 만들어 봅시다
  • 위의 posts 모델에는 다음과 같습니다
  • 는 모델 이벤트를 이벤트 클래스에 매핑하는 속성을 ​​추가했습니다. 즉, 모델이 생성되거나 업데이트되면 새 이벤트가 예정되어 있음을 의미합니다. 나중에이 이벤트 클래스를 만들 것입니다. IlluminateDatabaseEloquentSoftDeletes 관계를 정의합니다.
  피처를 사용하여 모델에서 소프트 삭제가 활성화됩니다.

  우리 모델이 준비되었으므로 및 AppModelsPost 이벤트 클래스를 만들어 봅시다.

  ##이벤트 클래스를 생성합니다 우리는 새 기사를 저장할 때 예정 될

  declare(strict_types=1);
  
  namespace App\Events;
  
  use App\Models\User;
  use Illuminate\Broadcasting\InteractsWithSockets;
  use Illuminate\Foundation\Events\Dispatchable;
  use Illuminate\Queue\SerializesModels;
  
  final class UserRegistered
  {
      use Dispatchable;
      use InteractsWithSockets;
      use SerializesModels;
  
      public function __construct(public User $user)
      {
          //
      }
  }

  이벤트 클래스를 만들 것입니다.

  위 코드에서는 이벤트 클래스를 볼 수 있으며,이 클래스는 생성자에서 모델 인스턴스를 허용합니다. 이 이벤트 클래스는 저장되는 기사 인스턴스를 저장하기위한 간단한 컨테이너입니다. <code>AppModelsPost 마찬가지로, 저자를 삭제할 때 예정 될

  이벤트 클래스를 만들 수 있습니다.
  위의
  • 클래스에서는 생성자가 모델 인스턴스를 수락한다는 것을 알 수 있습니다. dispatchesEvents 이제 우리는 청취자를 계속 만들 수 있습니다. saving #생성자를 강조하십시오 먼저 기사의 읽기 시간 추정을 계산하는 데 사용할 수있는 리스너를 만들어 봅시다. AppEventsPostSaving 우리는 새로운 AppEventsPostSaving 리스너 클래스를 만들 것입니다 :
  위의 코드에서 볼 수 있듯이 하나의
  • 메소드 만 있습니다. 이것은 author 이벤트를 예약 할 때 자동으로 호출되는 메소드입니다. 저장중인 기사가 포함 된
  이벤트 클래스의 인스턴스를 수락합니다.
  • IlluminateDatabaseEloquentSoftDeletes 방법에서는 간단한 공식을 사용하여 기사의 읽기 시간을 계산합니다. 이 예에서는 평균 판독 속도가 분당 265 단어라고 가정합니다. 우리는 읽기 시간을 몇 초 만에 계산 한 다음 기사 모델에서
  속성을 ​​설정합니다.
  이 리스너가 모델 이벤트가 트리거 될 때 호출되므로, 이는 기사를 작성하거나 업데이트하기 전에 기사가 데이터베이스에 지속될 때마다

  속성이 계산된다는 것을 의미합니다. saving 우리는 또한 저자를 부드럽게 삭제할 때 모든 관련 기사를 부드럽게 삭제하는 리스너를 만들 수 있습니다. read_time_in_seconds 우리는 새로운

  리스너 클래스를 만들 수 있습니다

  위의 리스너에서 메소드는 이벤트 클래스의 인스턴스를 허용합니다. 이 이벤트 클래스에는 저자가 삭제되는 것이 포함되어 있습니다. 그런 다음 저자의 기사를 삭제하기 위해 관계를 사용합니다.

  따라서 따라서

  모델이 부드럽게 삭제 될 때마다 모든 저자의 기사도 부드럽게 삭제됩니다. AppListenersSoftDeleteAuthorRelationships 그건 그렇고,이를 달성하기 위해보다 강력하고 재사용 가능한 솔루션을 사용하고 싶을 수도 있습니다. 그러나이 기사의 목적 상, 우리는 그것을 간단하게 유지합니다.

  클로저를 사용하여 모델 이벤트를 듣습니다

  declare(strict_types=1);
  
  namespace App\Events;
  
  use App\Models\User;
  use Illuminate\Broadcasting\InteractsWithSockets;
  use Illuminate\Foundation\Events\Dispatchable;
  use Illuminate\Queue\SerializesModels;
  
  final class UserRegistered
  {
      use Dispatchable;
      use InteractsWithSockets;
      use SerializesModels;
  
      public function __construct(public User $user)
      {
          //
      }
  }

  당신이 사용할 수있는 또 다른 방법은 리스너를 모델 자체의 클로저로 정의하는 것입니다.

  저자를 부드럽게 삭제할 때 소프트 삭제 기사의 예를 살펴 보겠습니다. 우리는 모델 이벤트에 대한 청소장을 포함하도록 모델을 업데이트 할 수 있습니다. handle 위의 모델에서 우리는 모델의 AppEventsAuthorDeleted 메소드에서 리스너를 정의하고 있음을 알 수 있습니다. 우리는 모델 이벤트를 듣고 싶습니다. 그래서 우리는 를 사용했습니다. 마찬가지로, 모델 이벤트에 대한 리스너를 만들려면 posts 등을 사용할 수 있습니다. 메소드는 delete가 삭제되는 것을 수신하는 클로저를 허용합니다. 이 폐쇄는 모델이 삭제되면 실행되므로 모든 저자 기사가 삭제됩니다.

  모델 클래스를 열 때 관찰자를 등록하는지 즉시 확인할 수 있기 때문에 청취자 로직을 정의하는 방법이 정말 마음에 듭니다. 따라서 논리는 여전히 별도의 파일에 "숨겨져"있지만, 우리는 최소한 하나의 모델 이벤트에 대해 청취자를 등록했음을 알 수 있습니다. 그러나 이러한 폐쇄의 코드가 더 복잡해지면 별도의 청취자 클래스로 논리를 추출하는 것이 좋습니다.

  편리한 속임수는 AppModelsAuthor 함수를 사용하여 클로저를 대기시킬 수 있다는 것입니다. 이는 리스너의 코드가 동일한 요청 수명주기가 아닌 백그라운드에서 실행되도록 대기열로 밀려 나게한다는 것을 의미합니다. 다음과 같이 리스너를 queuable로 업데이트 할 수 있습니다.

  위의 예에서 보았 듯이, 우리는

  함수로 클로저를 랩핑합니다.

  옵저버를 사용하여 모델 이벤트를 듣습니다

  모델 이벤트를들을 수있는 또 다른 방법은 모델 관찰자를 사용하는 것입니다. 모델 관찰자를 사용하면 한 클래스에서 모델의 모든 리스너를 정의 할 수 있습니다.

  일반적으로, 그들은

  ---

  디렉토리에 존재하는 클래스이며, 듣고 싶은 모델 이벤트에 해당하는 방법이 있습니다. 예를 들어, 모델 이벤트를 듣고 싶다면 관찰자 클래스에서

  메소드를 정의합니다. 모델 이벤트를 듣고 싶다면 관찰자 클래스에서

  메소드를 정의합니다.

  모델 이벤트를 듣는 모델을위한 모델 관찰자를 만드는 방법을 살펴 보겠습니다 : app/Observers 위의 코드에서 볼 수 있듯이 deleted 메소드가있는 관찰자를 만듭니다. 이 메소드는 deleted 모델의 인스턴스가 삭제되는 인스턴스를 허용합니다. 그런 다음 저자의 기사를 삭제하기 위해 관계를 사용합니다. created 예를 들어 도 및 모델 이벤트에 대한 청취자를 정의하고 싶다고 가정합니다. 우리는 다음과 같이 옵저버를 업데이트 할 수 있습니다 created 방법을 실행하려면 Laravel에게 사용하도록 지시해야합니다. 이를 위해

  속성을 ​​사용할 수 있습니다. 이를 통해 관찰자를 모델과 연결할 수 있습니다. 모델을 업데이트 할 수 있습니다.

  나는 청취자 논리를 정의하는 방법을 정말로 좋아합니다. 모델 클래스를 열 때 관찰자를 등록하는지 즉시 확인할 수 있기 때문입니다. 따라서 논리는 여전히 별도의 파일에 "숨겨져"있지만, 우리는 최소한 하나의 모델 이벤트에 대해 청취자를 등록했음을 알 수 있습니다. AppModelsAuthor 모델 이벤트를 테스트하십시오 deleted 어떤 모델 이벤트 메소드를 사용하든 논리가 예상대로 작동하는지 확인하기 위해 일부 테스트를 작성할 수 있습니다.

  위의 예제에서 만든 모델 이벤트를 테스트하는 방법을 살펴 보겠습니다.

  declare(strict_types=1);
  
  namespace App\Events;
  
  use App\Models\User;
  use Illuminate\Broadcasting\InteractsWithSockets;
  use Illuminate\Foundation\Events\Dispatchable;
  use Illuminate\Queue\SerializesModels;
  
  final class UserRegistered
  {
      use Dispatchable;
      use InteractsWithSockets;
      use SerializesModels;
  
      public function __construct(public User $user)
      {
          //
      }
  }

  저자가 부드럽게 삭제 될 때 저자의 기사가 부드럽게 삭제되도록 테스트를 작성합니다. 테스트는 다음과 같이 보일 수 있습니다

  위의 테스트에서 우리는 해당 저자를위한 새로운 저자와 기사를 만들고 있습니다. 그런 다음 저자를 부드럽게 삭제하고 저자와 기사가 모두 부드럽게 삭제되었다고 주장했습니다. deleted 이것은 우리의 논리가 예상대로 작동하는지 확인하는 데 사용할 수있는 매우 간단하지만 효과적인 테스트입니다. 이 테스트의 장점은이 기사에서 논의하는 각 방법과 함께 작동해야한다는 것입니다. 따라서이 기사에서 논의한 방법 중 하나를 전환하면 테스트가 여전히 전달되어야합니다. AppModelsAuthor 마찬가지로, 기사의 읽기 시간이 작성하거나 업데이트 될 때 계산되도록 몇 가지 테스트를 작성할 수 있습니다. 테스트는 다음과 같이 보일 수 있습니다

  우리는 두 가지 테스트가 있습니다 :

  첫 번째 테스트는 기사의 읽기 시간을 만들 때 계산되도록합니다.

  declare(strict_types=1);
  
  namespace App\Events;
  
  use App\Models\User;
  use Illuminate\Broadcasting\InteractsWithSockets;
  use Illuminate\Foundation\Events\Dispatchable;
  use Illuminate\Queue\SerializesModels;
  
  final class UserRegistered
  {
      use Dispatchable;
      use InteractsWithSockets;
      use SerializesModels;
  
      public function __construct(public User $user)
      {
          //
      }
  }

  두 번째 테스트는 기사의 읽기 시간이 기사를 업데이트 할 때 계산되도록합니다.
  모델 이벤트를 사용할 때의 예방 조치
• 모델 이벤트는 매우 편리하지만 사용할 때 알아야 할 몇 가지 문제가 있습니다.
모델 이벤트는 웅변 모델에서만 예약됩니다. 즉, 데이터베이스에서 모델의 기본 데이터와 상호 작용하기 위해
• Facade를 사용하는 경우 이벤트가 예약되지 않습니다.
예를 들어, 간단한 예를 살펴 보겠습니다.

Facade를 사용하여 저자를 삭제합니다.

위의 코드를 실행하면 예상대로 데이터베이스에서 저자를 삭제합니다. 그러나 모델 이벤트는 예약되지 않습니다. 따라서 저자를 삭제할 때 이러한 모델 이벤트에 대한 청취자를 정의하면 실행되지 않습니다. <hr> 마찬가지로, Eloquent를 사용하여 Batch 업데이트 또는 모델을 삭제하는 경우 , <p>, </p> 및 <p> 모델 이벤트는 영향을받는 모델에 대해 예약되지 않습니다. 이벤트는 모델 자체에서 예약되기 때문입니다. 그러나 배치 업데이트 및 삭제가 업데이트되면 모델은 실제로 데이터베이스에서 검색되지 않으므로 이벤트가 예약되지 않습니다. <code>IlluminateSupportFacadesDB 예를 들어 ^{다음 코드를 사용하여 저자를 삭제한다고 가정 해 봅시다.}

메소드는 쿼리 빌더에서 직접 호출되므로 및 모델 이벤트는 해당 저자에 대해 예약되지 않습니다. IlluminateSupportFacadesDB 고려하는 대체 방법

나는 프로젝트에서 모델 이벤트를 사용하는 것을 좋아합니다. 그들은 내 코드를 분리하는 좋은 방법으로 사용되며 모델에 영향을 미치는 코드를 많이 제어 할 수 없을 때 논리를 자동으로 실행할 수 있습니다. 예를 들어 Laravel Nova에서 저자를 삭제하면 저자를 삭제할 때 여전히 논리를 실행할 수 있습니다.

use App\Events\UserRegistered;
use App\Models\User;

$user = User::create([
    'name' => 'Eric Barnes',
    'email' => 'eric@example.com',
]);

UserRegistered::dispatch($user);

그러나 다른 방법을 사용하는 것을 고려해야 할시기를 아는 것이 중요합니다.

이를 설명하려면 모델 이벤트 사용을 피하고 싶은 기본 예를 살펴 보겠습니다. 새 게시물을 만들 때 다음을 실행할 것이라고 가정 한 이전 간단한 블로그 응용 프로그램 예제를 확장하십시오. deleting 기사의 읽기 시간을 계산하십시오. deleted > API 전화를 X/Twitter로 보내 기사를 공유하십시오.

플랫폼의 모든 가입자에게 알림을 보냅니다.

saved 따라서 새로운 인스턴스가 생성 될 때마다 실행되는 세 개의 별도 리스너 (각 작업마다 1 개)를 생성 할 수 있습니다. updated 그러나 이제 우리의 이전 테스트 중 하나를 검토합시다 : deleting

declare(strict_types=1);

namespace App\Events;

use App\Models\User;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

final class UserRegistered
{
    use Dispatchable;
    use InteractsWithSockets;
    use SerializesModels;

    public function __construct(public User $user)
    {
        //
    }
}

위의 테스트를 실행하면 모델이 공장을 통해 생성 될 때이 세 가지 작업을 트리거합니다. 물론 읽기 시간을 계산하는 것은 보조 작업이므로 중요하지 않습니다. 그러나 테스트 중에 API 호출을하거나 알림을 보내려고하지 않습니다. 이들은 예상치 못한 부작용입니다. 테스트를 작성하는 개발자가 이러한 부작용을 알지 못하면 이러한 작업이 발생하는 이유를 추적하기가 어려울 수 있습니다.

우리는 또한 청취자에 테스트 별 논리를 쓰지 않기를 원합니다. 이로 인해 테스트 중에 이러한 작업이 실행되는 것을 방지합니다. 이로 인해 응용 프로그램 코드가 더 복잡하고 유지하기가 더 어려워집니다. AppModelsPost 이것은 자동 모델 이벤트에 의존하기보다는보다 명백한 접근법을 고려하고 싶은 경우 중 하나입니다.

한 가지 방법은 생성 코드를 서비스 또는 액션 클래스로 추출하는 것입니다. 예를 들어, 간단한 서비스 클래스는 다음과 같습니다.

위의 클래스에서는 읽기 시간을 계산하고 알림을 보내고 게시물을 트위터에 수동으로 호출합니다. 즉, 이러한 작업이 진행되는시기를 더 잘 제어 할 수 있습니다. 또한 테스트에서 이러한 방법을 쉽게 조롱하여 실행을 방지 할 수 있습니다. 필요한 경우 이러한 작업을 여전히 대기시킬 수 있습니다 (이 경우 대부분 가능성이 높습니다).

따라서 이러한 작업의 모델 이벤트 및 리스너를 삭제할 수 있습니다. 이는 응용 프로그램 코드 에서이 새로운

클래스를 사용하고 테스트 코드에서 모델 팩토리를 안전하게 사용할 수 있음을 의미합니다.

이 작업의 추가 이점은 코드를 쉽게 이해할 수 있다는 것입니다. 내가 간단히 언급했듯이, 이벤트와 청취자를 사용하는 것에 대한 일반적인 비판은 예상치 못한 장소에서 비즈니스 논리를 숨길 수 있다는 것입니다. 따라서 새로운 개발자가 팀에 합류하면 모델 이벤트에 의해 유발되는 경우 일부 작업이 어디에서 발생하는지 또는 왜 발생하는지 알 수 없습니다.

그러나 여전히 그러한 논리에 이벤트와 청취자를 사용하려는 경우보다 명백한 접근 방식을 사용하는 것을 고려할 수 있습니다. 예를 들어, 서비스 클래스의 이벤트를 예약하여 리스너를 트리거 할 수 있습니다. 이런 식으로, 당신은 여전히 ​​이벤트와 청취자의 분리 장점을 사용할 수 있지만, 이벤트가 예정된시기를 더 잘 제어 할 수 있습니다. AppModelsPost 예를 들어 예를 들어, 예제에서 위의

메소드를 업데이트하여 이벤트를 예약 할 수 있습니다.

use App\Events\UserRegistered;
use App\Models\User;

$user = User::create([
    'name' => 'Eric Barnes',
    'email' => 'eric@example.com',
]);

UserRegistered::dispatch($user);

위의 방법을 사용하여 API 요청을 만들고 트위터에 알림을 보낼 별도의 리스너가있을 수 있습니다. 그러나 이러한 작업이 실행되는시기를 더 잘 제어 할 수 있으므로 모델 팩토리를 사용하여 테스트 할 때 실행되지 않습니다.

이러한 방법을 사용하기로 결정할 때는 황금률이 ​​없습니다. 그것은 모두 당신, 당신의 팀 및 당신이 구축하는 기능에 달려 있습니다. 그러나 나는 다음과 같은 경험의 규칙을 따르는 경향이 있습니다 :

리스너의 작업이 모델을 약간만 변경하는 경우 모델 이벤트 사용을 고려하십시오. 예 : 슬러그 생성, 읽기 시간 계산 등
• 작업이 다른 모델에 영향을 미치는 경우 (자동으로 작성, 업데이트 또는 삭제되었는지) 더 명확하고 모델 이벤트를 사용하지 않습니다.
작업이 외부 프로세스 (API 호출, 파일 처리, 트리거 알림, 대기열 작업)에서 작동하면 모델 이벤트를 사용하지 않는 것이 더 분명합니다.
모델 이벤트 사용의 장단점 이 기사에서 우리가 소개 한 내용을 신속하게 요약하려면 다음은 모델 이벤트 사용의 장점과 단점이 있습니다. #pros

코드를 분리하도록 권장합니다.

를 사용하면 모델이 작성/업데이트/삭제되는 곳에 관계없이 작업을 자동으로 트리거 할 수 있습니다. 예를 들어, 모델이 Laravel Nova에서 생성 된 경우 비즈니스 로직을 트리거 할 수 있습니다.

모델을 작성/업데이트/삭제할 때마다 이벤트를 예약하는 것을 기억할 필요가 없습니다.

---

#DisAdvantages

는 예상치 못한 부작용을 일으킬 수 있습니다. 일부 청취자를 트리거하지 않고 모델을 생성/업데이트/삭제할 수 있지만 예상치 못한 동작으로 이어질 수 있습니다. 이것은 테스트를 작성할 때 특히 문제가됩니다.

비즈니스 로직은 추적하기 어려운 예기치 않은 위치에 숨겨 질 수 있습니다. 이로 인해 코드 흐름을 이해하기가 더 어려워집니다.

• 결론
이 기사가 모델 이벤트가 무엇인지에 대한 개요와 다양한 사용 방법에 대한 개요를 제공하기를 바랍니다. 또한 모델 이벤트 코드를 테스트하는 방법과 사용할 때 알아야 할 몇 가지 문제를 보여 주어야합니다.
• 이제 Laravel 애플리케이션에서 모델 이벤트를 사용할 충분한 확신이 있어야합니다.

위 내용은 Laravel의 모델 이벤트에 대한 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!