はじめに
Laravelの「contracts」は、フレームワークが提供するコアサービスを定義するインターフェースのセットです。例えば、Illuminate\Contracts\Queue\Queue
契約はジョブをキューに入れるために必要なメソッドを定義し、Illuminate\Contracts\Mail\Mailer
契約はメールを送信するために必要なメソッドを定義します。
各契約には、フレームワークによって提供される対応する実装があります。例えば、Laravelはさまざまなドライバーを持つキューの実装と、Symfony Mailerによって動作するメール送信機能を提供します。
すべてのLaravel契約は独自のGitHubリポジトリに存在します。これにより、利用可能なすべての契約の迅速な参照ポイントが提供され、Laravelサービスと対話するパッケージを構築する際に利用できる単一のデカップルされたパッケージが得られます。
契約とファサード
Laravelのファサードとヘルパー関数は、サービスコンテナから契約をタイプヒントして解決することなく、Laravelのサービスを利用する簡単な方法を提供します。ほとんどの場合、各ファサードには同等の契約があります。
ファサードとは異なり、クラスのコンストラクタでそれらを要求する必要がない契約は、クラスの明示的な依存関係を定義することを可能にします。一部の開発者はこの方法で依存関係を明示的に定義することを好み、そのため契約を使用することを好みますが、他の開発者はファサードの便利さを楽しんでいます。一般的に、ほとんどのアプリケーションは開発中にファサードを問題なく使用できます。
契約を使用するタイミング
契約またはファサードを使用する決定は、個人の好みと開発チームの好みに依存します。契約とファサードの両方を使用して、堅牢で十分にテストされたLaravelアプリケーションを作成できます。契約とファサードは相互排他的ではありません。アプリケーションの一部はファサードを使用し、他の部分は契約に依存する場合があります。クラスの責任を集中させている限り、契約とファサードを使用することの実際的な違いはほとんどありません。
一般的に、ほとんどのアプリケーションは開発中にファサードを問題なく使用できます。複数のPHPフレームワークと統合するパッケージを構築している場合、illuminate/contracts
パッケージを使用して、Laravelのサービスとの統合を定義し、パッケージのcomposer.json
ファイルにLaravelの具体的な実装を要求する必要がないようにすることをお勧めします。
契約の使用方法
では、契約の実装をどのように取得しますか?実際には非常に簡単です。
Laravelの多くの種類のクラスは、サービスコンテナを通じて解決されます。これには、コントローラー、イベントリスナー、ミドルウェア、キューに入れられたジョブ、さらにはルートクロージャも含まれます。したがって、契約の実装を取得するには、解決されるクラスのコンストラクタでインターフェースを「タイプヒント」するだけです。
例えば、このイベントリスナーを見てください:
<?php
namespace App\Listeners;
use App\Events\OrderWasPlaced;
use App\Models\User;
use Illuminate\Contracts\Redis\Factory;
class CacheOrderInformation
{
/**
* Create a new event handler instance.
*/
public function __construct(
protected Factory $redis,
) {}
/**
* Handle the event.
*/
public function handle(OrderWasPlaced $event): void
{
// ...
}
}
イベントリスナーが解決されると、サービスコンテナはクラスのコンストラクタのタイプヒントを読み取り、適切な値を注入します。サービスコンテナにおける物事の登録について詳しくは、そのドキュメントを参照してください。
契約リファレンス
この表は、すべてのLaravel契約とその同等のファサードへの迅速な参照を提供します: