Lernen Sie, Abfragebereiche in Laravel zu meistern

<p> <img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/000/174119929536701.jpg" class="lazy" alt="Learn to master Query Scopes in Laravel"> </p> <p> Beim Erstellen einer Laravel -Anwendung müssen Sie möglicherweise Abfragen mit Einschränkungen schreiben, die an mehreren Stellen während der gesamten Anwendung verwendet werden. Vielleicht erstellen Sie eine Multi-Mieter-Anwendung und müssen der Abfrage ständig <code>where</code> Einschränkungen hinzufügen, um nach dem Nutzer-Team zu filtern. Oder vielleicht erstellen Sie einen Blog und müssen der Abfrage ständig <code>where</code> Einschränkungen hinzufügen, um zu filtern, wenn der Blog -Beitrag veröffentlicht wurde. </p> <p> In Laravel können wir Abfragebereiche verwenden, um uns zu helfen, diese Einschränkungen ordentlich an einem Ort zu halten und sie wiederzuverwenden. </p> <p> In diesem Artikel werden wir den lokalen Abfragebereich und den globalen Abfragebereich untersuchen. Wir werden den Unterschied zwischen den beiden lernen, wie Sie Ihren eigenen Abfragebereich erstellen und wie man Tests für sie schreibt. </p> <p> Nach dem Lesen dieses Artikels sollten Sie in Ihrer Laravel -Anwendung zuversichtlich Abfragebereichen verwenden können. </p> <h1> Was ist Abfrageumfang? </h1> <hr> Mit <p> Abfragebereich können Sie Einschränkungen in eloquenten Abfragen wiederverwendbar definieren. Sie werden normalerweise als Methoden auf dem Laravel -Modell oder als Klassen definiert, die <code>IlluminateDatabaseEloquentScope</code> Schnittstellen implementieren. </p> <p> Sie sind nicht nur ideal, um die wiederverwendbare Logik an einem Ort zu definieren, sondern können Ihren Code auch lesbarer machen, indem sie komplexe Abfrageinschränkungen nach einfachen Funktionsaufrufen verbergen. </p> <p> Abfragebereiche sind in zwei Typen unterteilt: </p> <ul> <li> Lokale Abfragebereiche - Sie müssen diese Bereiche manuell auf Ihre Anfrage anwenden. </li> <li> globale Abfragebereiche - Standardmäßig werden diese Bereiche auf alle Abfragen des Modells angewendet, vorausgesetzt, die Abfrage ist registriert. </li> </ul> <p> Wenn Sie jemals die in Laravel eingebaute Funktion "Soft Delete" verwendet haben, haben Sie möglicherweise den Abfragebereich unwissentlich verwendet. Laravel verwendet den lokalen Abfragebereich, um Ihnen Methoden wie <code>withTrashed</code> und <code>onlyTrashed</code> für das Modell zu bieten. Außerdem wird das globale Abfragebereich verwendet, um alle Abfragen auf dem Modell automatisch <code>whereNull('deleted_at')</code> Einschränkungen hinzuzufügen, sodass in der Abfrage nicht standardmäßig sanft gelöschte Datensätze zurückgegeben werden. </p> <p> Lassen Sie uns sehen, wie lokale Abfragebilder und globale Abfragebereiche in einer Laravel -Anwendung erstellt und verwendet werden. </p> <h1> Lokaler Abfragebereich </h1> <hr> <p> lokales Abfragebereich wird als Methode auf dem beredten Modell definiert, sodass Sie Einschränkungen definieren können, die manuell auf Modellabfragen angewendet werden können. </p> <p> Angenommen, wir erstellen eine Blog -Anwendung mit einem Admin -Panel. Im Admin -Panel haben wir zwei Seiten: eine für die Auflistung veröffentlichter Blog -Beiträge und die andere für die Auflistung unveröffentlichter Blog -Beiträge. </p> <p> wir gehen davon aus, dass auf den Blog -Beitrag mit dem <code>AppModelsArticle</code> -Modell zugegriffen wird und dass die Datenbanktabelle eine leere <code>published_at</code> -Spalte hat, um die Verlagszeit des Blog -Beitrags zu speichern. Wenn in der Vergangenheit <code>published_at</code> aufgeführt ist, wird angenommen, dass der Blog -Beitrag veröffentlicht wurde. Wenn <code>published_at</code> in Zukunft aufgeführt ist oder <code>null</code> ist, gilt der Blog -Beitrag als unveröffentlicht. </p> <p> Um veröffentlichte Blog -Beiträge zu erhalten, können wir die folgende Abfrage schreiben: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $publishedPosts = Article::query() ->where('published_at', '<', now()) ->get();</code></pre> <p> Um unveröffentlichte Blog -Beiträge zu erhalten, können wir die folgende Abfrage schreiben: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; use Illuminate\Contracts\Database\Eloquent\Builder; $unpublishedPosts = Article::query() ->where(function (Builder $query): void { $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }) ->get();</code></pre> <p> Die obige Abfrage ist nicht besonders kompliziert. Angenommen, wir verwenden sie an mehreren Stellen während der gesamten Anwendung. Mit zunehmender Anzahl der Ereignisse nimmt die Möglichkeit zu, dass wir Fehler machen oder vergessen, die Abfrage an einem Ort zu aktualisieren. Beispielsweise können Entwickler versehentlich <code>>=</code> anstelle von <code><</code> für die Abfrage veröffentlichte Blog -Beiträge verwenden. Alternativ kann sich die Logik zur Ermittlung eines Blog -Beitrags ändern, und wir müssen alle Abfragen aktualisieren. </p> <p> Hier sind Abfragebereiche sehr nützlich. Lassen Sie uns unsere Fragen organisieren, indem wir ein lokales Abfragebereich auf dem <code>AppModelsArticle</code> -Modell erstellen. </p> <p> lokale Abfragebereiche werden definiert, indem eine Methode erstellt wird, die mit <code>scope</code> beginnt und mit dem erwarteten Namen des Bereichs endet. Beispielsweise erstellt eine Methode namens <code>scopePublished</code> einen <code>published</code> -Spreis auf dem Modell. Diese Methode sollte eine <code>IlluminateContractsDatabaseEloquentBuilder</code> -Stanz akzeptieren und eine <code>IlluminateContractsDatabaseEloquentBuilder</code> -Instanz zurückgeben. </p> <p> Wir fügen dem <code>AppModelsArticle</code> -Modell beide Bereiche hinzu: </p> <pre class="brush:php;toolbar:false"><code>declare(strict_types=1); namespace App\Models; use Illuminate\Contracts\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Relations\BelongsTo; final class Article extends Model { public function scopePublished(Builder $query): Builder { return $query->where('published_at', '<', now()); } public function scopeNotPublished(Builder $query): Builder { return $query->where(function (Builder $query): Builder { return $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }); } // ... }</code> </p> <p> Wie wir im obigen Beispiel gesehen haben, haben wir die <code>where</code> Einschränkung aus der vorherigen Abfrage in zwei separate Methoden bewegt: <code>scopePublished</code> und <code>scopeNotPublished</code>. Wir können diese Bereiche jetzt in unserer Abfrage wie folgt verwenden: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $publishedPosts = Article::query() ->published() ->get(); $unpublishedPosts = Article::query() ->notPublished() ->get();</code></pre> <p> Meiner persönlichen Meinung nach finde ich diese Fragen leichter zu lesen und zu verstehen. Dies bedeutet auch, dass wir diese Bereiche wiederverwenden können, wenn wir in Zukunft Anfragen mit den gleichen Einschränkungen schreiben müssen. </p> <h1> globaler Abfragebereich </h1> <hr> <p> Global Query Scope erbringt Funktionen ähnlich wie die lokale Abfrage. Es wird jedoch nicht manuell auf Abfragen angewendet, sondern gilt automatisch für alle Abfragen des Modells. </p> <p> Wie bereits erwähnt, verwendet die integrierte "Soft Delete" -Funktion von Laravel <code>IlluminateDatabaseEloquentSoftDeletingScope</code> globaler Abfragebereich. Dieser Bereich fügt automatisch <code>whereNull('deleted_at')</code> Einschränkungen zu allen Abfragen des Modells hinzu. Wenn Sie daran interessiert sind, zu verstehen, wie es funktioniert, können Sie hier den Quellcode auf GitHub überprüfen. </p> <p> Angenommen, Sie erstellen eine Multi-Mieter-Blog-Anwendung mit einem Admin-Panel. Möglicherweise möchten Sie Benutzern nur erlauben, Artikel anzusehen, die zu ihrem Team gehören. Sie können also eine solche Frage schreiben: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $publishedPosts = Article::query() ->where('published_at', '<', now()) ->get();</code></pre> <p> Diese Abfrage ist gut, aber es ist leicht zu vergessen, <code>where</code> Einschränkungen hinzuzufügen. Wenn Sie eine andere Abfrage schreiben und vergessen, Einschränkungen hinzuzufügen, werden Sie einen Fehler in Ihrer Anwendung haben, der es dem Benutzer ermöglicht, mit Artikeln zu interagieren, die nicht Teil seines Teams sind. Natürlich wollen wir nicht, dass dies passiert! </p> <p> Um dies zu verhindern, können wir einen globalen Bereich erstellen, den wir automatisch für alle unsere <code>AppModelArticle</code> Modellabfragen anwenden können. </p> <h3> #Wow, um einen globalen Abfragebereich zu erstellen </h3> <p> Erstellen wir einen globalen Abfragebereich, der alle Abfragen nach der Spalte <code>team_id</code> filtert. </p> <p> Bitte beachten Sie, dass wir für die Zwecke dieses Artikels das Beispiel einfach halten. In einer realen Anwendung möchten Sie möglicherweise einen leistungsstärkeren Ansatz für den Umgang mit Situationen verwenden, wie der Benutzer nicht authentifiziert ist oder der Benutzer zu mehreren Teams gehört. Aber im Moment halten wir es einfach, damit wir uns auf das Konzept des globalen Abfragebereichs konzentrieren können. </p> <p> Wir werden zuerst den folgenden Kunsthandwerk im Terminal ausführen: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; use Illuminate\Contracts\Database\Eloquent\Builder; $unpublishedPosts = Article::query() ->where(function (Builder $query): void { $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }) ->get();</code></pre> <p> Dies hätte eine neue <code>app/Models/Scopes/TeamScope.php</code> Datei erstellen sollen. Wir werden einige Updates für diese Datei erstellen und dann den fertigen Code ansehen: </p> <pre class="brush:php;toolbar:false"><code>declare(strict_types=1); namespace App\Models; use Illuminate\Contracts\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Relations\BelongsTo; final class Article extends Model { public function scopePublished(Builder $query): Builder { return $query->where('published_at', '<', now()); } public function scopeNotPublished(Builder $query): Builder { return $query->where(function (Builder $query): Builder { return $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }); } // ... }</code></pre> <p> In dem obigen Codebeispiel können wir sehen, dass wir eine neue Klasse haben, die die <code>IlluminateDatabaseEloquentScope</code> -Rumentation implementiert und eine einzelne Methode namens <code>apply</code> hat. So definieren wir die Einschränkungen, die für Modellabfragen angewendet werden sollen. </p> <p> Unser globaler Bereich ist jetzt verfügbar. Wir können dies zu jedem Modell hinzufügen, das wir die Abfrage an das Benutzerteam eingrenzen möchten. </p> <p> Wenden wir es auf das <code>AppModelsArticle</code> -Modell an. </p> <h3> #Apply Global Query Scope </h3> <p> Es gibt verschiedene Möglichkeiten, den globalen Umfang auf das Modell anzuwenden. Die erste Methode besteht darin, das Attribut <code>IlluminateDatabaseEloquentAttributesScopedBy</code> im Modell zu verwenden: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $publishedPosts = Article::query() ->published() ->get(); $unpublishedPosts = Article::query() ->notPublished() ->get();</code></pre> <p> Eine andere Methode besteht darin, die <code>booted</code> -Methode in der Methode des Modells zu verwenden: <code>addGlobalScope</code> </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $articles = Article::query() ->where('team_id', Auth::user()->team_id) ->get();</code></pre> Beide Methoden wenden die <p> Einschränkungen auf alle Abfragen auf dem <code>where('team_id', Auth::user()->team_id)</code> -Modell an. <code>AppModelsArticle</code> </p> Dies bedeutet, dass Sie jetzt Abfragen schreiben können, ohne sich über die Filterung nach <p> Spalte zu sorgen: <code>team_id</code> </p> <pre class="brush:php;toolbar:false"><code>php artisan make:scope TeamScope</code></pre> Wenn wir davon ausgehen, dass der Benutzer einem Team mit <p> <code>team_id</code> gehört, wird die folgende SQL für die obige Abfrage generiert: <code>1</code> </p> <pre class="brush:php;toolbar:false"><code>declare(strict_types=1); namespace App\Models\Scopes; use Illuminate\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Scope; use Illuminate\Support\Facades\Auth; final readonly class TeamScope implements Scope { /** * Apply the scope to a given Eloquent query builder. */ public function apply(Builder $builder, Model $model): void { $builder->where('team_id', Auth::user()->team_id); } }</code></pre> Das ist cool, oder? ! <p> </p> #anonymous Global Query Scope <h3> </h3> Eine andere Möglichkeit, einen globalen Abfragebereich zu definieren und anzuwenden, besteht darin, einen anonymen globalen Bereich zu verwenden. <p> </p> Aktualisieren wir unser <p> Modell, um den anonymen globalen Bereich zu verwenden: <code>AppModelsArticle</code> </p> <pre class="brush:php;toolbar:false"><code>declare(strict_types=1); namespace App\Models; use App\Models\Scopes\TeamScope; use Illuminate\Database\Eloquent\Attributes\ScopedBy; use Illuminate\Database\Eloquent\Model; #[ScopedBy(TeamScope::class)] final class Article extends Model { // ... }</code></pre> In dem obigen Codebeispiel verwendeten wir die <p> -Methode, um den anonymen globalen Umfang in der <code>addGlobalScope</code> -Methode des Modells zu definieren. <code>booted</code> Methode akzeptiert zwei Parameter: <code>addGlobalScope</code></p> <ul> <li> Der Name des Umfangs - Wenn Sie ihn in Ihrer Abfrage ignorieren müssen, können Sie diesen Namen verwenden, um sich auf das Zielfernrohr zu verweisen </li> <li> Umfangsbeschränkungen - Definieren Sie den Verschluss, um auf die Einschränkungen zu gelten </li> </ul> <p> wie bei anderen Methoden wendet dies die <code>where('team_id', Auth::user()->team_id)</code> -Erbeschränkung auf alle Abfragen auf dem <code>AppModelsArticle</code> -Modell an. </p> <p> meiner Erfahrung nach ist anonymer globaler Umfang nicht so häufig wie das Definieren des globalen Umfangs in einer separaten Klasse. Es ist jedoch vorteilhaft zu wissen, dass sie in Notfällen verfügbar sind. </p> <h3> #ignore Global Query Scope </h3> <p> Manchmal möchten Sie möglicherweise eine Abfrage schreiben, die nicht den globalen Abfragebereich verwendet, der auf das Modell angewendet wurde. Zum Beispiel erstellen Sie möglicherweise einen Bericht oder eine Analyseabfrage, die unabhängig vom globalen Abfragebereich alle Aufzeichnungen enthalten muss. </p> <p> Wenn dies der Fall ist, können Sie eine von zwei Methoden verwenden, um den globalen Bereich zu ignorieren. </p> <p> Die erste Methode ist <code>withoutGlobalScopes</code>. Mit dieser Methode können Sie alle globalen Bereiche des Modells ignorieren, wenn keine Parameter an sie übergeben werden: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $publishedPosts = Article::query() ->where('published_at', '<', now()) ->get();</code></pre> <p> oder, wenn Sie nur einen bestimmten Satz globaler Bereiche ignorieren möchten, können Sie den Umfangsnamen an die <code>withoutGlobalScopes</code> -Methode übergeben: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; use Illuminate\Contracts\Database\Eloquent\Builder; $unpublishedPosts = Article::query() ->where(function (Builder $query): void { $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }) ->get();</code></pre> <p> Im obigen Beispiel ignorieren wir <code>AppModelsScopesTeamScope</code> und einen anderen fiktiven anonymen globalen Bereich namens <code>another_scope</code>. </p> <p> oder, wenn Sie nur einen einzelnen globalen Bereich ignorieren möchten, können Sie die <code>withoutGlobalScope</code> -Methode verwenden: </p> <pre class="brush:php;toolbar:false"><code>declare(strict_types=1); namespace App\Models; use Illuminate\Contracts\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Relations\BelongsTo; final class Article extends Model { public function scopePublished(Builder $query): Builder { return $query->where('published_at', '<', now()); } public function scopeNotPublished(Builder $query): Builder { return $query->where(function (Builder $query): Builder { return $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }); } // ... }</code></pre> <h3> #Precauutions für den globalen Abfragebereich </h3> <p> <code>IlluminateSupportFacadesDB</code> Es ist wichtig, sich daran zu erinnern, dass der globale Abfragebereich nur auf Abfragen angewendet wird, die über das Modell erstellt wurden. Wenn Sie Datenbankabfragen mit dem Aussehen </p> schreiben, wird der globale Abfragebereich nicht angewendet. <p> </p> Angenommen, Sie haben diese Abfrage geschrieben und möchten, dass sie nur Artikel zum Team von angemeldeten Benutzern kriechen: <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $publishedPosts = Article::query() ->published() ->get(); $unpublishedPosts = Article::query() ->notPublished() ->get();</code></pre> <p> <code>AppModelsArticle</code> In der obigen Abfrage wird auch wenn der globale Abfragebereich von <code>AppModelsScopesTeamScope</code> auf dem </p> -Modell definiert ist, der Bereich nicht angewendet. Daher müssen Sie sicherstellen, dass die Einschränkungen in der Datenbankabfrage manuell angewendet werden. <h1> </h1> Testen Sie den lokalen Abfragebereich <hr> <p> </p> <p> Jetzt, da wir gelernt haben, wie man Abfragebereiche erstellt und verwendet, werden wir uns ansehen, wie man Tests für sie schreibt. </p> <p> Es gibt verschiedene Möglichkeiten, den Umfang einer Abfrage zu testen, und die Methode, die Sie auswählen, kann von Ihrer persönlichen Präferenz oder dem Inhalt des von Ihnen geschriebenen Umfangs abhängen. Zum Beispiel möchten Sie möglicherweise mehr Tests im Einheitsstil für den Umfang schreiben. Alternativ möchten Sie möglicherweise mehr Integrationsstil -Tests schreiben, die den Umfang in Kontexten wie Controllern testen. </p> <p> Persönlich mische ich die beiden gerne, damit ich sicher sein kann, dass das Zielfernrohr die richtigen Einschränkungen hinzufügt und dass der Bereich tatsächlich in der Abfrage verwendet wird. <code>published</code> <code>notPublished</code> Beginnen wir mit den vorherigen Beispielen </p> und -Rang und schreiben einige Tests für sie. Wir müssen zwei verschiedene Tests schreiben (eine für jeden Bereich): <ul> <li> A Test Check <code>published</code> Range gibt nur veröffentlichte Artikel zurück. </li> <li> A Test Check <code>notPublished</code> Bereich gibt nur unveröffentlichte Artikel zurück. </li> </ul> <p> Schauen wir uns diese Tests an und diskutieren dann, was getan wird: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; $publishedPosts = Article::query() ->where('published_at', '<', now()) ->get();</code></pre> <p> Wir können in der obigen Testdatei sehen, wir erstellen zunächst einige Daten in der <code>setUp</code> -Methode. Wir haben zwei veröffentlichte Artikel erstellt, einen außerplanmäßigen Artikel und einen arrangierten Artikel. </p> <p> Dann gibt es einen Test (<code>only_published_articles_are_returned</code>), der den Bereich <code>published</code> überprüft, um nur veröffentlichte Artikel zurückzugeben. Es gibt auch einen Test (<code>only_not_published_articles_are_returned</code>), der den <code>notPublished</code> -Reiche überprüft, um nur unveröffentlichte Artikel zurückzugeben. </p> <p> Auf diese Weise können wir jetzt sicher sein, dass unser Abfragebereich wie erwartet Einschränkungen anwendet. </p> <h1> Testbereich in Controller </h1> <hr> <p> Wie bereits erwähnt, besteht eine andere Möglichkeit, den Umfang einer Abfrage zu testen, um sie im Kontext zu testen, das im Controller verwendet wird. Während die Isolationstests von Scopes behaupten können, dass der Umfang der Abfrage die richtigen Einschränkungen hinzufügt, wird nicht tatsächlich getestet, ob der Bereich wie erwartet in der Anwendung verwendet wird. Sie können beispielsweise vergessen, einer Abfrage in der Controller -Methode einen <code>published</code> Bereich hinzuzufügen. </p> <p> Diese Arten von Fehlern können durch Schreiben von Tests erfasst werden, die behauptet, dass die korrekten Daten bei der Verwendung von Scopes in Controller -Methoden zurückgeführt werden. </p> <p> Nehmen wir das Beispiel für eine Blog-Anwendung mit mehreren Mietern und schreiben Sie einen Test für die Controller-Methode, in der die Artikel aufgeführt sind. Nehmen wir an, wir haben eine sehr einfache Controller -Methode wie folgt: </p> <pre class="brush:php;toolbar:false"><code>use App\Models\Article; use Illuminate\Contracts\Database\Eloquent\Builder; $unpublishedPosts = Article::query() ->where(function (Builder $query): void { $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }) ->get();</code></pre> <p> wir gehen davon aus, dass das <code>AppModelsArticle</code> Modell unser <code>AppModelsScopesTeamScope</code> angewendet hat. </p> <p> Wir werden behaupten, dass wir nur Artikel zurückgeben, die zum Benutzerteam gehören. Der Testfall könnte so aussehen: </p> <pre class="brush:php;toolbar:false"><code>declare(strict_types=1); namespace App\Models; use Illuminate\Contracts\Database\Eloquent\Builder; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Relations\BelongsTo; final class Article extends Model { public function scopePublished(Builder $query): Builder { return $query->where('published_at', '<', now()); } public function scopeNotPublished(Builder $query): Builder { return $query->where(function (Builder $query): Builder { return $query->whereNull('published_at') ->orWhere('published_at', '>', now()); }); } // ... }</code></pre> <p> Im obigen Test erstellen wir zwei Teams. Dann erstellen wir einen Benutzer, der zu Team One gehört. Wir haben 3 Artikel für Team 1 und 2 Artikel für Team 2 erstellt. Wir fungieren dann als Benutzer und stellen eine Anfrage an die Controller -Methode, die die Artikel auflistet. Die Controller -Methode sollte nur 3 Artikel von Team One zurückgeben. Daher behaupten wir, dass nur diese Artikel durch Vergleich der Artikel -IDs zurückgegeben werden. </p> <p> Dies bedeutet, dass wir sicher sein können, dass der globale Abfragebereich wie erwartet in der Controller -Methode verwendet wird. </p> <h1> Schlussfolgerung </h1> <hr> <p> In diesem Artikel haben wir etwas über den lokalen Abfragebereich und den globalen Abfragebereich erfahren. Wir haben die Unterschiede zwischen ihnen gelernt, wie man sie erstellt und verwendet und wie man Tests für sie schreibt. </p> <p> Ich hoffe, Sie sollten jetzt in Ihrer Laravel -Anwendung zuversichtlich Abfragebereichen verwenden können. </p>

Das obige ist der detaillierte Inhalt vonLernen Sie, Abfragebereiche in Laravel zu meistern. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!