Laravel 5.5コアアーキテクチャの詳細説明

この記事では主にLaravel 5.5のコアアーキテクチャについて詳しく紹介しており、必要な方はエディターと一緒に学習しましょう。

1. 依存性注入メソッド

コンポーネント名を入力すると、フレームワークが自動的にインスタンスを作成し、メソッド内で直接使用できます

たとえば、最も一般的に使用されるリクエストオブジェクト

2.コンテナ

実際、Laravel のコアは単なる IoC コンテナです。Laravel のコア自体は非常に軽量であり、魔法のような、または実質的なアプリケーション機能はありません。 Route（ルーティング）、Eloquent ORM（データベースORMコンポーネント）、Request（リクエスト）、Response（レスポンス）など、多くの人が利用するさまざまな機能モジュールは、実はコアとは関係のないクラスモジュールによって提供されています。これらのクラスの登録からインスタンス化、そして最終的に使用されるまでのプロセスは、実際には Laravel のサービス コンテナーの責任です。

サービスプロバイダーは主に register (登録) と boot (ブート、初期化) の 2 つの部分に分かれています

3. サービスプロバイダー

クラスをコンテナーによって抽出するには、最初にクラスをコンテナーに登録する必要があります。 Laravel はこのコンテナをサービスコンテナと呼ぶため、サービスが必要な場合は、まずサービスを登録してコンテナにバインドする必要があります。次に、サービスを提供し、サービスをコンテナにバインドするのがサービスプロバイダです。

4. 独自のクラスを IOC コンテナに追加します

4.1. 新しい検証クラスを作成します

4.3. 新しい検証クラスを Provider にバインドします

4.4.プロバイダを IOC コンテナに追加します

4.5、

4.6 を使用します、成功しました!

5. ファサード

facade は、Redis または memcache のどちらのキャッシュを使用しても、クライアントは、cache::get() メソッドを使用して値を取得できます。 Redis を使用するか memcahe を使用するかは、サービスプロバイダーにどちらをバインドするかによって異なります。 Cache::get() の実装は、Facade メソッド getFacadeAccessor を継承し、キャッシュなどのコンテナーにバインドしたキー値を返します。その後、Facade クラスは PHP マジック変数 __callstatic() のロジックを使用します。 5.1. たとえば、config/app.php のメールは 1 つのメーラー

のみを返します。

5.3. send メソッドを呼び出すと、それが存在しない場合、callstatic マジックメソッドに入ります

5.4. このメソッドは、メーラーのインスタンス、つまり app('mailer') を取得します。

5.5. このインスタンスはメーラークラスの send メソッドを呼び出すことができます

6. Contract

Laravel のコントラクトは、フレームワークによって提供されるコアサービスを定義するインターフェイスのセットです。たとえば、IlluminateContractsQueueQueue コントラクトはタスクのキューイングに必要なメソッドを定義し、IlluminateContractsMailMailer コントラクトは電子メールの送信に必要なメソッドを定義します。フレームワークは、各コントラクトに対応する実装を提供します。

利点は、低結合とプログラムのシンプルさを実現できることです。

低結合#

まず、高結合キャッシュ実装のコードを見てみましょう。以下のように:

<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
class ValidateProvider extends ServiceProvider
{
 /**
 * Bootstrap the application services.
 *
 * @return void
 */
 public function boot()
 {
 //
 }

 /**
 * Register the application services.
 *
 * @return void
 */
 public function register()
 {
 $this->app->bind('valicate',function(){
  return new Validate();
 });
 }
}

このクラスでは、プログラムは指定されたキャッシュと高度に結合されています。拡張パッケージの特定のキャッシュ クラスに依存しているためです。この拡張機能の API が変更されたら、それに応じてコードも変更する必要があります。

同様に、基礎となるキャッシュ テクノロジ (Memcached) を別のキャッシュ テクノロジ (Redis) に置き換える場合は、リポジトリ クラスを再度変更する必要があります。リポジトリ クラスは、データの提供者やデータがどのように提供されたかなどについて、あまり多くを知る必要はありません。

上記のアプローチと比較して、拡張パッケージに依存しないシンプルなインターフェイスを使用してコードを改善できます。

<?php
namespace App\Orders;
use Illuminate\Contracts\Cache\Repository as Cache;
class Repository
{
 /**
 * 缓存实例。
 */
 protected $cache;

 /**
 * 创建一个仓库实例。
 *
 * @param Cache $cache
 * @return void
 */
 public function __construct(Cache $cache)
 {
 $this->cache = $cache;
 }
}

现在，更改之后的代码没有与任何扩展包甚至是 Laravel 耦合。而契约扩展包不包含任何实现和依赖项，你可以轻松地写任何给定契约的替代实现，来实现不修改任何关于缓存消耗的代码就可以替换缓存实现。

相关推荐：

Laravel 5.5实现前后台登陆

如何实现Laravel 5.5可响应接口

Laravel 5.5中为响应请求提供的可响应接口详解_php实例

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