Laravelフレームワークのコアアーキテクチャの詳細な説明

次のチュートリアル コラムでは、Laravel フレームワークのコア アーキテクチャについて詳しく紹介します。

laravel フレームワークを使用したことのある友人は、いくつかの基本的な機能 (コントローラー、ビュー、モデルなど) を提供することに加えて、中間パーツもあることを知っています。 、ファサード、コントラクトなど。これらはlaravelフレームワークでどのように使用されますか?今日は詳しくお話しましょう。

デザイン コア
、laravel フレームワークはサービス コンポーネント開発モデルを使用して開発されており、laravel フレームワークはさまざまな要素で構成されています) を理解する必要があります。サービスコンポーネント)

laravel の複数のサービスプロバイダーは、laravel コンポーネントを構成します。階層設計: 同じ機能を持つクラス ライブラリを同じフォルダーに配置します。 laravelフレームワークにはサービスを構成する複数のクラスがあり、複数のサービスがコンポーネントを構成します。 クラス -> サービス -> コンポーネント

Laravel はコンポーネントベースの開発モデルを使用します、
複数のクラス -> サービス -> コンポーネント、複数のクラスがサービス、複数のサービスを構成するコンポーネント。
複数のコンポーネントが異なるサービスを提供し、複数のサービスがプロジェクトを構成します。

理論的には、ライフ サイクルには主に次の段階があります。しかし、その中で、ほとんどの開発者は、ルーティング、ミドルウェア、コントローラー、クロージャ関数、ロジック処理などにのみ焦点を当てる必要があります。
もちろん、各ステップ内にはさらに詳細な実行プロセスが存在します。フレームワークを深く研究したり、フレームワークを変革したりすることはなく、詳細な研究を行うことはめったにありませんが、最下層を研究することは依然として学習には良い選択です。

サービスとは、必要なものを提供するという意味で、laravelで提供されるサービスには、認証サービス、データベースサービス、キャッシュサービス、キューサービスなどが含まれます。 laravel フレームワークのすべてのサービスは
app/config/app.php

サービスプロバイダー で定義されており、一連のサービスを提供できます。問題はサービスプロバイダーであり、上記のように実際にlaravelで定義されているサーバープロバイダー（

など）が認証サービスを提供するサービスプロバイダーです。
IlluminateCacheCacheServiceProvider::class、キャッシュ サービスを提供するサービス プロバイダー
利点:開発者は、プロジェクト ロジックやさまざまな開発担当者に対処するためのエネルギーをより節約できます。最も重要なことは、プロジェクトが階層的な分離を達成することです。ビジネス ロジックはサービスにのみ依存し、サービスの基盤となる実装には依存しません。 切り離した後、基盤となるクラスがサービスを実装している限り、サービスの基盤となる実装を自由にアップグレードまたはカスタマイズできます。

要約: 実際、サービスは抽象概念、サーバー プロバイダーは、この抽象概念の具体的な実装者です。

すべてのサービスを 1 つのボックスに入れて、サービス コンテナを格納します。 laravelのサービスコンテナは

vendor/laravel/frameworksrcilluminateContainerContainer.php.

Container.phpにあります。これはlaravelフレームワークのサービスコンテナです。

は、サービス プロバイダーの形式、メソッド、パラメーターなどを計画するために使用され、サービス プロバイダーに対する特定の制約を規制します。したがって、フレームワーク内のすべてのコントラクトはインターフェースであるため、サービスプロバイダーを標準化できます。

ファサード
ファサードは、Laravel の優れたデザインを改めて示しています。これにより、Laravel はより柔軟になり、拡張が容易になります。そして、そのコンセプトは次のとおりです。

2 これは、サービス アクセス メソッドを補足します。サービスを使用する前に、サービスのインスタンスを取得してから、サービス メソッドを呼び出す必要がありました。ただし、ファサードを使用すると、サービスは静的オブジェクトとして直接呼び出されます。 3 config/app.php のサービス エイリアス alias のほとんどは facade を使用します

4 facade を使用するのは危険です。使用すればするほど良いというわけではありません。これは、少量の紹介ですが、詳細は開発中にまだ発見する必要があります

Laravel フレームワークの全体的なアーキテクチャ図

如上图所示：laravel框架是由多个服务组件构成的 -> 服务提供者（最下面的不同的服务组件）。
Foundation 的 Application 用来创建服务提供者，创建好之后保存在Container 的 Container 的服务容器里面，交由他管理，Application 要继承 Container。
为了约定服务提供者提供的服务，我们定义一个规范，这就是契约。
 
对于我们的用户（最上面的用户）想使用laravel框架，必须通过控制器来使用（上面的Controller），使用laravel框架主要是使用laravel里面的服务提供者（上面的 new 服务），这样就是最传统的开发模式，和服务器容器没有直接关系，如果laravel这样设计的话，基本上和其他框架一样，没有任何优势。所以一般不怎么做。
 
由于有契约，契约是服提供者的接口，所以我们也可以直接使用契约，new 服务旁边的黄色线。使用契约用注入的方式，这样使用的不好之处是如果一个方法里面使用多个契约的话，我们就得注入多个契约，这样代码看起来不优雅。

 
于是laravel里面就出现了门面，门面的出现方便我们优雅的调用服务器提供者的类。由于每个服务提供者的类太长了如：

IlluminateCookieCookieServiceProvider::class,IlluminateDatabaseDatabaseServiceProvider::class,

所以又引出了别名，使用别名之后 简化了我们调用的服务提供者的类。

事件：laravel里面的模型里面的事件，比如用户对数据库操作时做的一个监听。对整个项目运行进行监听，有监听的动作。类似tp5里面的钩子和行为。
中间件：做用户的请求做一定的过滤。

以上がLaravelフレームワークのコアアーキテクチャの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。