Detaillierte Analyse des Anforderungslebenszyklus der Anwendungsimplementierung des thinkPHP5.0-Frameworks

In diesem Artikel wird hauptsächlich der Lebenszyklus von thinkPHP5.0-Framework-Anwendungen vorgestellt und die verschiedenen Ausführungsprozesse im Lebenszyklus von thinkPHP5.0-Framework-Anwendungen detailliert analysiert Bedarf kann sich beziehen auf Dieser Artikel beschreibt den Anwendungsanforderungslebenszyklus des thinkPHP5.0-Frameworks anhand von Beispielen. Teilen Sie es als Referenz mit allen. Die Details lauten wie folgt:

In diesem Artikel geben wir eine allgemeine Einführung in den Lebenszyklus von Anwendungsanforderungen in ThinkPHP5.0, damit Entwickler die gesamte Ausführung verstehen können Verfahren.

1.

Eintragsdatei

Anfragen, die von Benutzern initiiert werden, durchlaufen die Eintragsdatei der Anwendung, normalerweise die Datei public/index.php. Selbstverständlich können Sie auch Eintragsdateien ändern oder neue hinzufügen.

Normalerweise ist der Code der Eintragsdatei relativ einfach wie folgt:

Allgemeine Eintragsdateien haben einige

Konstanten

// 应用入口文件
// 定义项目路径
define('APP_PATH', DIR . '/../application/');
// 加载框架引导文件
require DIR . '/../thinkphp/start.php';

definiert werden hauptsächlich unterstützt. Bitte beachten Sie den folgenden Inhalt oder Anhang für Konstanten.

Im Allgemeinen empfehlen wir nicht, zu viel Code zur Anwendungseintragsdatei hinzuzufügen, insbesondere keinen Code im Zusammenhang mit der Geschäftslogik.

2. Boot-Datei

Der nächste Schritt ist die Boot-Datei des Ausführungsframeworks. Die Datei start.php ist die Standard-Boot-Datei des Systems. In der Boot-Datei werden die folgenden Vorgänge nacheinander ausgeführt:

① Systemkonstantendefinitionen laden

③ Den automatischen Lademechanismus registrieren; 🎜>④ Registrieren Sie den Fehler- und Ausnahmebehandlungsmechanismus.

⑥ Führen Sie die Anwendung aus.

Im oben genannten Ausführungsprozess können sich Änderungen ergeben.


3. Registrieren Sie sich für das automatische Laden

Das System ruft die Methode Loader::register() auf, um sich für das automatische Laden zu registrieren 🎜>, die den Spezifikationen entsprechen Klassenbibliotheken

(einschließlich Klassenbibliotheken von Drittanbietern, deren Laden Composer erfordert) werden automatisch geladen.

Das automatische Laden des Systems besteht aus zwei Teilen:

① Die automatische Lademethode des Registrierungssystems thinkLoader::autoload② Der Namespace des Registrierungssystems

Definition

③ Laden Sie die Zuordnungsdatei der Klassenbibliothek (sofern vorhanden)

④ Wenn eine Composer-Installation vorhanden ist, registrieren Sie Composer für das automatische Laden

⑤ Registrieren Sie das Extend-Erweiterungsverzeichnis
Automatisches Laden einer Klassenbibliothek. Die Reihenfolge der Ladeerkennung ist:

① Ob die Klassenbibliothekszuordnung definiert werden soll
② PSR-4 automatische Ladeerkennung; 0 automatische Ladeerkennung;

Wie Sie sehen, ist die Definition der Klassenbibliothekszuordnung am effizientesten.

4. Fehler- und Ausnahmemechanismus registrieren

Führen Sie Error::register() aus, um den Fehler- und Ausnahmebehandlungsmechanismus zu registrieren.

besteht aus drei Teilen:

① Methode zum Herunterfahren der Anwendung: thinkError::appShutdown<strong></strong>② Fehlerbehandlungsmethode

: thinkError::appError<p></p>③ Ausnahmebehandlungsmethode:

Die Registrierung der Methode zum Herunterfahren der Anwendung dient dazu, das Abfangen einiger Systemfehler zu erleichtern.

thinkError::appShutdown<br>Wenn während des gesamten Lebenszyklus einer Anwendungsanforderung eine Ausnahme oder ein schwerwiegender Fehler ausgelöst wird, wird die Anwendung vorzeitig beendet und antwortet mit einer Ausnahme und einer Fehlermeldung. thinkError::appError<br>thinkError::appException

5. Anwendungsinitialisierung

Der erste Schritt zum Ausführen einer Anwendung ist die Initialisierung der Anwendung, einschließlich:

Laden der Anwendung ( öffentliche) Konfiguration;

Alias-Definition laden; Erweiterte Konfigurationsdatei laden (definiert durch extra_config_list); 🎜 >Laden Sie die Erweiterungsfunktionsdatei (definiert durch extra_file_list); Laden Sie das Systemsprachenpaket

URL-Zugriff Erkennung


Nachdem die Anwendungsinitialisierung abgeschlossen ist, wird eine URL-Zugriffserkennung durchgeführt, einschließlich PATH_INFO-Erkennung und URL-Suffix-Erkennung.

5.0 URL-Zugriff muss eine URL-Adresse im PATH_INFO-Modus (einschließlich Kompatibilitätsmodus) sein, zum Beispiel:


serverName/index.php/index/index/hello/val/value

Wenn Ihre Umgebung also nur den normalen URL-Parameterzugriff unterstützen kann, müssen Sie serverName/index.php?s=/index/index/hello&val =value verwenden

Wenn Sie über die Befehlszeile auf die Eintragsdatei zugreifen, können Sie fortfahren, nachdem Sie die normalen

Parameter über

erhalten haben.

7. Routenerkennung

Wenn der Parameter url_route_on aktiviert ist, wird zuerst die URL-Routenerkennung durchgeführt.

如果一旦检测到匹配的路由，根据定义的路由地址会注册到相应的URL调度。

5.0的路由地址支持如下方式：

路由到模块/控制器/操作；
路由到外部重定向地址；
路由到控制器方法；
路由到闭包函数；
路由到类的方法；

路由地址可能会受域名绑定的影响。

如果关闭路由或者路由检测无效则进行默认的模块/控制器/操作的分析识别。

如果在应用初始化的时候指定了应用调度方式，那么路由检测是可选的。

可以使用 \think\App::dispatch() 进行应用调度。

8、分发请求

在完成了URL检测和路由检测之后，路由器会分发请求到对应的路由地址，这也是应用请求的生命周期中最重要的一个环节。

在这一步骤中，完成应用的业务逻辑及数据返回。

建议统一使用return返回数据，而不是echo输出，如非必要，请不要执行exit中断。

直接echo输出的数据将无法进行自动转换响应输出的便利。

下面是系统支持的分发请求机制，可以根据情况选择：

模块/控制器/操作

这是默认的分发请求机制，系统会根据URL或者路由地址来判断当前请求的模块、控制器和操作名，并自动调用相应的访问控制器类，执行操作对应的方法。

该机制下面，首先会判断当前模块，并进行模块的初始化操作（和应用的初始化操作类似），模块的配置参数会覆盖应用的尚未生效的配置参数。

支持模块映射、URL参数绑定到方法，以及操作绑定到类等一些功能。

控制器方法

和前一种方式类似，只是无需判断模块、控制器和操作，直接分发请求到一个指定的控制器类的方法，因此没有进行模块的初始化操作。

外部重定向

可以直接分发请求到一个外部的重定向地址，支持指定重定向代码，默认为301重定向。

闭包函数

路由地址定义的时候可以直接采用闭包函数，完成一些相对简单的逻辑操作和输出。

类的方法

除了以上方式外，还支持分发请求到类的方法，包括：
静态方法： 

'blog/:id'=>'\org\util\Blog::read'

类的方法：

'blog/:id'=>'\app\index\controller\Blog@read'

9、响应输出

控制器的所有操作方法都是return返回而不是直接输出，系统会调用Response::send方法将最终的应用返回的数据输出到页面或者客户端，并自动转换成default_return_type参数配置的格式。所以，应用执行的数据输出只需要返回一个正常的PHP数据即可。

10、应用结束

事实上，在应用的数据响应输出之后，应用并没真正的结束，系统会在应用输出或者中断后进行日志保存写入操作。

系统的日志包括用户调试输出的和系统自动生成的日志，统一会在应用结束的时候进行写入操作。

而日志的写入操作受日志初始化的影响。

Das obige ist der detaillierte Inhalt vonDetaillierte Analyse des Anforderungslebenszyklus der Anwendungsimplementierung des thinkPHP5.0-Frameworks. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!