라벨 모델 팁

Laravel은 개발 경험 (DX)을 향상시키는 데 도움이되는 많은 강력한 기능을 제공합니다. 그러나 정기적 인 릴리스, 일상적인 작업의 스트레스 및 수많은 사용 가능한 기능의 출현으로 코드를 개선하는 데 도움이되는 덜 알려진 기능을 쉽게 놓칠 수 있습니다.

이 기사에서는 내가 가장 좋아하는 Laravel 모델 사용 팁을 소개합니다. 이 팁이 클리너,보다 효율적인 코드를 작성하고 일반적인 함정을 피하는 데 도움이되기를 바랍니다.

N 1 문제를 발견하고 방지하십시오 우리는 먼저 n 1 쿼리 문제를 발견하고 방지하는 방법을 소개합니다.

연관이로드가 지연되면 일반적인 n 1 쿼리 문제가 발생할 수 있습니다. 여기서 n은 관련 모델을 얻기 위해 실행되는 쿼리 수입니다.

이것이 무엇을 의미합니까? 예를 살펴 보겠습니다. 데이터베이스에서 모든 게시물을 가져 와서 반복하고 게시물을 만든 사용자에게 액세스하려고한다고 가정하십시오. 우리의 코드는 다음과 같이 보일 수 있습니다 :

위의 코드는 좋아 보이지만 실제로는 n 1 문제를 일으 킵니다. 데이터베이스에 100 개의 게시물이 있다고 가정합니다. 첫 번째 줄에서는 모든 게시물을 얻기 위해 단일 쿼리를 실행합니다. 그런 다음 에 액세스하는 루프에서 새 쿼리가 트리거되어 게시물 사용자가 추가로 제공됩니다. 이는 총 101 개의 쿼리를 실행한다는 것을 의미합니다. 당신이 상상할 수 있듯이, 이것은 좋지 않습니다! 응용 프로그램이 느려지고 데이터베이스에 불필요한 압력 을가합니다.

코드가 점점 더 복잡해지고 이러한 문제를 적극적으로 찾고 있지 않으면 기능이 점점 더 어려워집니다.

고맙게도 Laravel은 이러한 N 1 문제를 발견하고 예방하는 데 도움이되는 편리한

방법을 제공합니다. 이 방법은 LaRavel에게 게으른 관계를 적재 할 때 예외를 던지도록 지시하므로 관계가 항상 열심히로드되도록 할 수 있습니다.

이 메소드를 사용하려면 메소드 호출을 클래스에 추가하십시오 : .

이제, 우리가 위의 코드를 실행하여 각 게시물을 가져 와서 해당 게시물을 만든 사용자에게 액세스하려면 다음 메시지와 함께

예외가 발생합니다.

이 문제를 해결하기 위해 게시물을 얻을 때 사용자 관계를 간절히로드하기 위해 코드를 업데이트 할 수 있습니다. 방법을 사용하여 다음을 달성 할 수 있습니다

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

위의 코드는 이제 성공적으로 실행되며 두 개의 쿼리 만 트리거됩니다. 하나는 모든 게시물을 가져 오기위한 것입니다.

누락 된 에 대한 액세스를 방지하기위한 속성 모델에 존재하지만 존재하지 않는 필드에 얼마나 자주 액세스하려고합니까? 오류를 입력했을 수도 있고 실제로

필드가 있다고 생각할 수도 있습니다.

우리가 다음 필드를 가진

모델을 가지고 있다고 가정 해 full_name name

AppModelsUser

• id
• name
• 다음 코드를 실행하면 어떻게됩니까? : email
우리가 모델에 액세서가 없다고 가정 해 봅시다. 그러나 이것이
• 필드가 실제로 password이거나 데이터베이스에서 필드를 얻지 못했거나 필드가 모델에 존재하지 않기 때문인지 알 수 없습니다. 당신이 상상할 수 있듯이, 이것은 예기치 않은 행동으로 이어질 수 있으며 때로는 감지하기 어려울 수 있습니다.
Laravel 은이 문제를 예방하는 데 사용할 수있는
• 메소드를 제공합니다. 이 방법은 Laravel에게 모델의 현재 인스턴스에 존재하지 않는 필드에 액세스하려고 할 때 예외를 던지도록 지시합니다. created_at 이 기능을 활성화하려면 메소드 호출을
클래스에 추가하십시오 : .
• 이제 샘플 코드를 실행하고 모델의 updated_at 필드에 액세스하려고하면 다음 메시지와 함께 예외가 발생합니다.

를 사용하는 또 다른 이점은 존재하지만 모델에로드되지 않을 수있는 필드를 읽으려고 시도하는 상황을 강조한다는 것입니다. 예를 들어, 다음 코드가 있다고 가정합니다

누락 된 속성에 대한 액세스를 차단하면 다음 예외가 발생합니다.

이것은 기존 쿼리를 업데이트 할 때 매우 유용합니다. 예를 들어, 과거에는 모델에 몇 개의 필드 만 필요했을 수 있습니다. 그러나 현재 응용 프로그램의 기능을 업데이트하고 다른 필드에 액세스해야 할 수도 있습니다. 이 방법이 활성화되지 않은 경우 아직로드되지 않은 필드에 액세스하려고한다는 사실을 알지 못할 수 있습니다.

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

메소드가 Laravel Documentation (Commit)에서 제거되었지만 여전히 작동한다는 점에 주목할 가치가 있습니다. 왜 그것이 제거되었는지 잘 모르겠지만주의의 문제입니다. 이것은 미래에 삭제 될 것임을 나타낼 수 있습니다. full_name $name (다음 내용은 원본 텍스트와 동일합니다. 일관성을 유지하기 위해 원본 텍스트를 유지하고 더 이상 다시 쓰지 않습니다) . 속성의 무음 폐기 방지 와 유사하게, Laravel은 모델을 업데이트 할 때 예상치 못한 동작을 방지하는 데 도움이되는

방법을 제공합니다. preventAccessingMissingAttributes 당신이 다음과 같이 preventSilentlyDiscardingAttributes 우리가 볼 수 있듯이, , 및

필드는 모두 채우실 수있는 필드입니다. 그러나 모델에 존재하지 않는 필드 (예 : ) 또는 존재하지만 채울 수없는 필드 (예 : )를 업데이트하려고하면 어떻게됩니까? :

AppModelsUser 위의 코드를 실행하면 필드가 충전 가능한 필드로 정의되지 않기 때문에 및

필드가 모두 무시됩니다. 그러나 오류가 발생하지 않으므로이 필드가 조용히 버렸다는 것을 알지 못할 것입니다.

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

예상대로, 특히 "업데이트"문의 다른 내용이 실제로 업데이트 된 경우 응용 프로그램에서 찾기 어려운 오류가 발생할 수 있습니다. 따라서

메소드를 사용할 수 있습니다.이 메소드는 존재하지 않거나 모델에서 채울 수없는 필드를 업데이트하려고 할 때 예외를 던집니다. name 이 메소드를 사용하려면 메소드 호출을 클래스에 추가하십시오 : . email 위의 코드는 오류가 발생하게됩니다. password 이제 위의 샘플 코드를 실행하고 사용자의 full_name 및 필드를 업데이트하려고하면 다음 메시지와 함께 예외가 발생합니다. email_verified_at 메소드는 또는 와 같은 메소드를 사용할 때만 채워지지 않은 필드 만 강조 표시한다는 점에 주목할 가치가 있습니다. 각 속성을 수동으로 설정하면 이러한 오류가 발생하지 않습니다. 예를 들어 다음 코드를 살펴 보겠습니다

위 코드에서 필드는 데이터베이스에 존재하지 않으므로 Laravel은 우리를 위해이를 캡처하지 않고 데이터베이스 수준에서 캡처합니다. MySQL 데이터베이스를 사용하는 경우 다음과 같은 오류가 표시됩니다. <pre class="brush:php;toolbar:false">namespace App\Providers; use Illuminate\Database\Eloquent\Model; use Illuminate\Support\ServiceProvider; class AppServiceProvider extends ServiceProvider { public function boot(): void { Model::preventLazyLoading(); } }</pre> <ict> 엄격한 모델 모드 <to> 앞에서 언급 한 세 가지 메소드를 사용하려면 메소드를 사용하여 한 번에 활성화 할 수 있습니다. 이 메소드는 <ables ables>, <p> 및 <code>full_name 설정을 활성화합니다. email_verified_at 이 메소드를 사용하려면 메소드 호출을 클래스에 추가하십시오 : .

이것은 다음과 같습니다

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

메소드와 유사하게

메소드는 Laravel 문서 (Commit)에서 제거되었지만 여전히 작동합니다. 이것은 미래에 삭제 될 것임을 나타낼 수 있습니다. preventAccessingMissingAttributes UUID 사용 shouldBeStrict

기본적으로 Laravel 모델은 자동 인상 ID를 기본 키로 사용합니다. 그러나 때로는 UUID (Universal Cight Identifier)를 사용하는 것을 선호 할 수도 있습니다.

uuid는 자원을 고유하게 식별하는 데 사용할 수있는 128 비트 (또는 36 자)의 영숫자 문자열입니다. 그들이 어떻게 생성되는지 때문에, 다른 UUID와 충돌 할 가능성은 매우 낮습니다. UUID의 예는 다음과 같습니다.

당신은 UUID를 모델의 주요 키로 사용하고 싶을 수도 있습니다. 또는 응용 프로그램 및 데이터베이스의 관계를 정의하기 위해 자동 증가 ID를 유지하지만 공개 ID에는 UUID를 사용하여 자동 증가 된 ID를 유지할 수 있습니다. 이 접근법을 사용하면 공격자가 다른 리소스의 ID를 추측하기가 더 어려워서 추가 보안 계층을 추가 할 수 있습니다.

예를 들어 라우팅에서 자동 인상 ID를 사용한다고 가정 해 봅시다. 아래와 같이 사용자에게 액세스하기위한 경로가있을 수 있습니다.

경로가 안전하지 않은 경우 공격자는 ID (예 : - ,

,

등)를 통해 다른 사용자의 프로파일에 액세스하려고 시도 할 수 있습니다. 그리고 UUID를 사용하면 URL은 1fa24c18-39fd-4ff2-8f23-74ccd08462b0,

및 와 비슷할 수 있습니다. 당신이 상상할 수 있듯이, 이것들은 추측하기가 더 어렵습니다.

물론 UUID를 사용하는 것은 응용 프로그램을 보호하지 않고 보안을 향상시키기 위해 취할 수있는 추가 단계 일뿐입니다. 속도 제한, 인증 및 승인 검사와 같은 다른 보안 조치를 사용해야합니다.

uuid를 기본 키로 사용하십시오 먼저 기본 키를 UUID로 변경하는 방법을 살펴 보겠습니다.

이렇게하려면 테이블에 uuids를 저장할 수있는 열이 있는지 확인해야합니다. Laravel은 마이그레이션에 사용할 수있는 편리한

namespace App\Providers;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Model::preventLazyLoading();
    }
}

방법을 제공합니다.

우리가 이것이 /users/1 테이블의 기본 마이그레이션을 만들었다고 가정 해 /users/2 우리가 마이그레이션에서 보았 듯이, 우리는 UUID 필드를 정의했습니다. 기본적 으로이 필드는 라고 불리며, 원하는 경우 열 이름을 /users/3 메소드로 전달하여 변경할 수 있습니다. /users/1fa24c18-39fd-4ff2-8f23-74ccd08462b0 그런 다음 Laravel에게 새로운 /users/b807d48d-0d01-47ae-8bbc-59b2acea6ed3 필드를 모델의 주요 키로 사용하도록 지시해야합니다. 또한 Laravel이 자동으로 UUID를 생성 할 수있는 기능을 추가해야합니다. 우리는 모델의 /users/ec1dde93-c67a-4f14-8464-c0d29c95425f 속성을 ​​덮어 쓰고

속성을 ​​사용하여이를 수행 할 수 있습니다.

이제 모델을 구성하고 UUID를 기본 키로 사용할 준비가되어 있어야합니다. 이 샘플 코드를 살펴 보겠습니다

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

우리는 덤프 모델에서

필드가 UUID로 채워져 있음을 알 수 있습니다. uuid 모델에 uuid 필드를 추가하십시오 내부 관계에 자동 증가 된 ID를 사용하려는 경우 공개 ID에 UUID를 사용하는 경우 모델에 UUID 필드를 추가 할 수 있습니다.

우리는 당신의 테이블에 및

필드가 있다고 가정합니다. 우리는 필드를 기본 키로 사용하므로 모델의

속성을 ​​정의 할 필요가 없습니다.

우리는 기능에 의해 제공된

메소드를 무시할 수 있습니다. 이 방법은 UUID를 생성 해야하는 다양한 필드를 반환해야합니다.

우리가 부르는 필드를 포함하도록 모델을 업데이트합시다. id 이제 새로운 모델을 덤프하려면 uuid 필드가 uuid로 채워져 있음을 알 수 있습니다. id 우리는 나중에이 기사에서 모델과 경로를 업데이트하는 방법을 설명하여 이러한 UUID가 귀하의 경로에서 공개 ID로 사용되도록합니다. $primaryKey ulid를 사용하십시오 Laravel 모델에서 UUID를 사용하는 것과 유사하게, 때로는 ULID (Universal Cight Dictionary Sort Identifier)를 사용하고 싶을 수도 있습니다.

ulid는 자원을 고유하게 식별하는 데 사용할 수있는 128 비트 (또는 26 자)의 영숫자 문자열입니다. ulid의 예는 다음과 같습니다.

. IlluminateDatabaseEloquentConcernsHasUuids UUID 필드를 정의 할 때 ulid 필드를 정의 할 수 있습니다. 유일한 차이점은 모델을 업데이트하는 대신 uniqueIds 기능을 사용하여

기능을 사용해야한다는 것입니다.

예를 들어, 모델을 기본 키로 사용하도록 업데이트하려면 다음을 수행 할 수 있습니다. AppModelsComment 라우팅 모델 바인딩에 사용되는 필드를 변경하십시오 당신은 이미 라우팅 모델 바인딩이 무엇인지 알고있을 것입니다. 그러나 당신이 모르는 경우를 대비하여, 간단히 되돌아 보자. uuid 라우팅 모델 바인딩을 사용하면 Laravel 애플리케이션 경로로 전달 된 데이터에 따라 모델 인스턴스를 자동으로 얻을 수 있습니다.

기본적으로 Laravel은 모델의 1 차 키 필드 (일반적으로

namespace App\Providers;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Model::preventLazyLoading();
    }
}

필드)를 사용하여 모델 바인딩을 라우팅합니다. 예를 들어, 개별 사용자 정보를 표시하기위한 경로가있을 수 있습니다.

위 예제에 정의 된 경로는 데이터베이스에있는 사용자를 찾아서 제공된 ID를 갖습니다. 예를 들어, 데이터베이스에 ID가 가있는 사용자가 있다고 가정합니다. URL 에 액세스하면 Laravel은 데이터베이스에서 id AppModelsComment로 사용자를 자동으로 얻고 작업을 위해 Closure Function (또는 컨트롤러)으로 전달됩니다. 그러나 데이터베이스에 제공된 ID가있는 모델이 없으면 Laravel은 자동으로 응답을 반환합니다. uuid 그러나 때로는 기본 키가 아닌 다른 필드를 사용하여 데이터베이스에서 모델을 검색하는 방법을 정의 할 수도 있습니다.

예를 들어, 앞에서 언급했듯이, 자동 증가 된 ID를 내부 관계를위한 모델의 주요 키로 사용하고 싶을 수도 있습니다. 그러나 공개 ID에 UUID를 사용하고 싶을 수도 있습니다. 이 경우

필드가 아닌 라우팅 모델 바인딩에

필드를 사용할 수 있습니다. uuid 마찬가지로, 블로그를 작성하는 경우 id 필드 대신 필드를 기반으로 게시물을 얻을 수 있습니다. 이는 필드를 읽기 쉽고 자동 증가 된 ID보다 SEO 친화적이기 때문입니다.

모든 라우팅 된 필드를 변경하십시오 모든 경로에 적용되는 필드를 정의하려면 모델에서

메소드를 정의하여이를 수행 할 수 있습니다. 이 방법은 라우팅 모델 바인딩에 사용하려는 필드의 이름을 반환해야합니다. slug 예를 들어, ^{필드 대신 필드를 사용하기 위해 모델에 대한 모든 라우팅 모델 바인딩을 변경하려고한다고 가정 해 봅시다. 우리는 모델에 id 메소드를 추가하여이를 수행 할 수 있습니다 : slug 이것은 이제 우리가 다음과 같이 경로를 정의 할 수 있음을 의미합니다.}

우리가 URL 에 액세스 할 때 Laravel은 데이터베이스에서 로 를 자동으로 가져 와서 작업을 위해 폐쇄 함수 (또는 컨트롤러)로 전달합니다.

단일 경로의 필드를 변경 그러나 때로는 단일 경로에서 사용되는 필드 만 변경하고 싶을 수도 있습니다. 예를 들어, 모델 바인딩을 라우팅하기 위해 한 경로에서 getRouteKeyName 필드를 사용하려면 다른 모든 경로에서

필드를 사용하려고합니다.

우리는 라우팅 정의에서 AppModelsPost 구문을 사용하여이를 수행 할 수 있습니다. 예를 들어, 라우팅 모델 바인딩 경로에서 slug 필드를 사용한다고 가정 해 봅시다. 우리는 다음과 같이 경로를 정의 할 수 있습니다 id 이것은 이제이 특정 경로에서 Laravel이 제공된 Post 필드와 함께 데이터베이스에서 게시물을 얻으려고한다는 것을 의미합니다. getRouteKeyName 사용자 정의 모델 컬렉션 사용 데이터베이스에서 여러 모델을 얻기 위해 와 같은 메소드를 사용하면 Laravel은 일반적으로

클래스의 인스턴스에 넣습니다. 이 클래스는 반환 된 모델을 처리하는 데 많은 유용한 방법을 제공합니다. 그러나 때로는 기본 수집 클래스 대신 사용자 정의 컬렉션 클래스를 반환 할 수도 있습니다.

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

몇 가지 이유로 사용자 정의 컬렉션을 만들고 싶을 수도 있습니다. 예를 들어, 해당 유형의 모델 처리에 특정한 도우미 방법을 추가 할 수 있습니다. 또는 유형 안전성을 향상시키기 위해 사용하고 컬렉션에 특정 유형의 모델 만 포함되어 있는지 확인할 수 있습니다.

laravel을 사용하면 반환 해야하는 컬렉션 유형을 쉽게 재정의 할 수 있습니다.

예를 살펴 보겠습니다. 우리가 모델을 가지고 있다고 가정하고 데이터베이스에서 가져 오면 사용자 정의 클래스의 인스턴스로 반환하려고합니다. AppModelsPost 우리는 새로운 파일을 만들고 사용자 정의 컬렉션 클래스를 다음과 같이 정의 할 수 있습니다. AppCollectionsPostCollection 위의 예에서, 우리는 Laravel의 클래스를 확장하는 새로운

클래스를 만들었습니다. 또한이 컬렉션에는 docBlock을 사용하여 app/Collections/PostCollection.php 클래스의 인스턴스 만 포함하도록 지정했습니다. 이는 IDE가 컬렉션에 포함될 데이터 유형을 이해하도록 돕는 데 유용합니다.

그런 다음 다음과 같이

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

메소드를 재정의하여 사용자 정의 컬렉션 클래스의 인스턴스를 반환하기 위해 모델을 업데이트 할 수 있습니다.

이 예에서는 모델 배열을 메소드로 전달하고 사용자 정의 AppCollectionsPostCollection 이제 아래에 표시된 것처럼 사용자 정의 컬렉션 클래스를 사용하여 데이터베이스에서 게시물을 가져올 수 있습니다. IlluminateSupportCollection 비교 모델 프로젝트를 수행 할 때의 일반적인 문제는 모델을 비교하는 방법입니다. 사용자가 리소스에 액세스 할 수 있는지 확인하려면 일반적으로 승인 검사에 있습니다. AppModelsPost 일반적인 함정과 왜 피해야하는지 살펴 보겠습니다.

두 모델이 동일한 지 확인할 때

를 사용하지 않아야합니다. AppModelsPost가 객체를 비교할 때 확인하면 동일한 객체의 인스턴스인지 확인하기 때문입니다. 이것은 두 모델이 동일한 데이터를 가지고 있더라도 다른 인스턴스 인 경우 동일하게 간주되지 않음을 의미합니다. 따라서 newCollection가 반환 될 가능성이 높기 때문에이 작업을 피해야합니다.

namespace App\Providers;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Model::preventLazyLoading();
    }
}

관계가 모델에 존재하고 데이터베이스의 첫 번째 주석이 첫 번째 게시물에 속한다고 가정 해 봅시다. 예를 들여다 보자.

두 모델이 동일한 지 확인할 때는 newCollection를 사용하지 않아야합니다. 이는 객체를 비교할 때 AppModelsPost를 점검하면 동일한 클래스의 인스턴스 여부와 동일한 속성과 값이 있는지 확인하기 때문입니다. 그러나 이것은 예상치 못한 행동으로 이어질 수 있습니다. AppCollectionsPostCollection 이 예를 살펴보십시오 :

위의 예에서 검사는 및

가 동일한 클래스이고 동일한 속성과 값을 갖기 때문에 를 반환합니다. 그러나 우리가 모델의 속성을 변경하여 다르게 만들면 어떻게됩니까?

<code>尝试在模型 [App\Models\Post] 上延迟加载 [user]，但延迟加载已禁用。</code>

메소드를 사용하여

테이블에서 및

필드 만 가져 오도록하겠습니다.

$posts = Post::all();

foreach ($posts as $post) {
    // 对帖子执行某些操作...

    // 尝试访问帖子的用户
    echo $post->user->name;
}

가 와 동일하더라도 는 모델에 다른로드 된 속성이 있기 때문에 검사는 $comment->post를 반환합니다. 당신이 상상할 수 있듯이, 이것은 추적하기 어려운 이해할 수없는 행동으로 이어질 수 있습니다. 특히 $post 메소드를 쿼리에 소급 적으로 추가하고 테스트가 실패하기 시작한 경우. == 대신, 나는 Laravel이 제공 한 및 false 메소드를 사용하는 것을 좋아합니다. 이 방법은 두 모델을 비교하고 동일한 클래스에 속하는지 확인하고 동일한 기본 키 값을 갖고 동일한 데이터베이스 연결이 있는지 확인합니다. 이것은 모델을 비교하는 안전한 방법이며 예상치 못한 행동의 가능성을 줄이는 데 도움이됩니다. select 당신은

메소드를 사용하여 두 모델이 동일한 지 확인할 수 있습니다.

마찬가지로, is 메소드를 사용하여 두 모델이 다른지 확인할 수 있습니다. isNot

쿼리를 구축 할 때

is를 사용하십시오 마지막 트릭은 개인적 선호도와 비슷하지만 쿼리를 읽고 이해하기 쉽게 만들었습니다.

데이터베이스에서 모델을 얻으려고 할 때 관계 기반 필터링 쿼리를 작성할 수 있습니다. 예를 들어, 특정 사용자에게 속한 모든 주석을 얻고 게시 할 수 있습니다.

namespace App\Providers;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Model::preventLazyLoading();
    }
}

laravel은 쿼리를보다 쉽게 ​​읽을 수 있도록 사용할 수있는

메소드를 제공합니다 (내 의견으로는). 이 방법을 사용하면 위의 쿼리를 다음과 같이 다시 작성할 수 있습니다. isNot 나는이 구문 설탕을 좋아하고 쿼리를 더 쉽게 읽을 수 있다고 생각합니다. 이것은 또한 올바른 관계 및 필드를 기반으로 필터를 필터링 할 수있는 좋은 방법입니다.

귀하 또는 귀하의 팀은

<code>尝试在模型 [App\Models\Post] 上延迟加载 [user]，但延迟加载已禁用。</code>

클로스 작성에보다 명백한 접근 방식을 사용하는 것을 선호 할 수 있습니다. 따라서이 기술은 모든 사람에게 적합하지 않을 수 있습니다. 그러나 나는 당신이 당신의 접근 방식을 일관성있게 유지하는 한 둘 다 좋다고 생각합니다.

whereBelongsTo 결론 이 기사에서 Laravel 모델을 사용하기위한 몇 가지 새로운 팁을 보여주기를 바랍니다. 이제 N 1 문제를 발견하고 방지하고, 누락 된 속성에 대한 액세스를 방지하고, 조용히 버려지는 속성을 방지하며, 기본 키 유형을 UUID 또는 ULID로 변경하십시오. 또한 라우팅 모델 바인딩에 사용되는 필드를 변경하는 방법을 알고, 컬렉션 유형을 지정하고, 모델을 비교하고, 쿼리를 구축 할 때

를 사용하십시오.

위 내용은 라벨 모델 팁의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!