Deutsch
Deutsch
In der PHP -Entwicklung, insbesondere bei der Verwendung von Frameworks wie Laravel, fällen wir häufig zu Beurteilungen eingehender Anforderungsobjekte in Controllern oder Middleware. Dieses Szenario ist besonders häufig, wenn eine unterschiedliche Logik für bestimmte Arten von Anfragen wie API -Anforderungen oder benutzerdefinierte Anforderungsklassen erforderlich ist. In diesem Artikel wird vorgestellt, wie die Funktion is_a () verwendet wird, um den Art des angeforderten Objekts und die Vorteile dieser Methode zu bestimmen.
Angenommen, wir haben eine Middleware, die entscheiden muss, ob die nachfolgende Logik weiter ausführt, basierend darauf, ob es sich bei der Anforderung um eine bestimmte benutzerdefinierte Anfrageklasse handelt. Beispielsweise können wir eine benutzerdefinierte Anforderungsklasse -App \ http \ requests \ apirequest für API -Anfragen erstellen, die von Illuminate \ http \ Anfragen erben . In diesem Fall müssen wir zwischen normalen Anfragen und API -Anfragen in der Middleware unterscheiden.
PHP bietet eine Vielzahl von Möglichkeiten, um Objekttypen zu beurteilen, einschließlich des Instanzoperators und der Funktion IS_A () . Obwohl die beiden Funktionen ähnlich sind, bietet IS_A () eine flexiblere Funktionsaufrufmethode, insbesondere für dynamische Typ -Beurteilungsszenarien.
Die Syntax ist wie folgt:
is_a(object|string $object_or_class, string $class, bool $allow_string = false): bool
Wenn $ degly_string auf true eingestellt ist, können Sie die Klassennamenzeichenfolge anstelle des Objekts übergeben.
Hier ist ein einfaches Beispiel für Middleware. Wir verwenden IS_A (), um festzustellen, ob die Anforderung von Apirequest Typ ist:
<?php
namespace App\Http\Middleware;
use Closure;
use Illuminate\Http\Request;
use App\Http\Requests\ApiRequest;
class CheckApiRequest
{
public function handle(Request $request, Closure $next)
{
if (is_a($request, ApiRequest::class)) {
// gegen API Fordern Sie die Ausführungslogik an
// Zum Beispiel Protokollierung、Fügen Sie spezielle Header -Informationen usw. hinzu.
}
return $next($request);
}
}
Wenn im obigen Code das eingehende Anforderungsobjekt eine Instanz der Apirequest -Klasse ist, kann eine bestimmte Logik ausgeführt werden. Andernfalls wird es direkt an die nächste Middleware oder Controller übergeben.
Die gleiche Logik gilt für den Controller. Zum Beispiel in einer Controller -Methode:
public function store(Request $request)
{
if (is_a($request, \App\Http\Requests\ApiRequest::class)) {
// bewältigen API Die Logik der Anfrage
return response()->json(['message' => 'Das ist API fragen']);
}
// 普通fragen逻辑
return view('form-submitted');
}
Dies ermöglicht eine einfache Implementierung der differenzierten Verarbeitung verschiedener Arten von Anforderungen nach derselben Controller -Methode.
Manchmal erhalten wir dynamisch Klassennamen in Konfigurationsdateien oder anderen Quellen, und die Vorteile von IS_A () werden reflektiert. Beispiele sind wie folgt:
$className = 'App\Http\Requests\ApiRequest';
if (is_a($request, $className)) {
// 逻辑bewältigen
}
Dies ist bei der Implementierung von Plug-in-Systemen oder modularen Architekturen sehr praktisch.
Die Verwendung von IS_A () , um den Typ des Anforderungsobjekts zu bestimmen, ist ein klarer, flexibler und hoch lesbarer Ansatz, insbesondere in Middleware und Controllern, die unterschiedliche Antworten auf den Anforderungsart erfordern. Im Vergleich zu Instanzen ist IS_A () besser für dynamische Szenarien geeignet und hat auch die gleiche Leistung und Genauigkeit.
Indem Sie diesen Ansatz rational verwenden, können Sie Ihre Anwendung modular und klarer machen, wenn sie eine komplexe Anforderungslogik bearbeiten. Wenn Sie diese Methode weiter üben möchten, können Sie sich auf den folgenden Link finden Sie weitere Codebeispiele:
