この記事では主に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中为响应请求提供的可响应接口详解_php实例
以上がLaravel 5.5コアアーキテクチャの詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。