検索

ホームページ >バックエンド開発 >PHPチュートリアル >PHPマスター|再利用性を向上させるために、PSR-3でロギングします

PHPマスター|再利用性を向上させるために、PSR-3でロギングします

尊渡假赌尊渡假赌尊渡假赌
尊渡假赌尊渡假赌尊渡假赌オリジナル
2025-02-24 10:42:15974ブラウズ

PHP Master | Logging with PSR-3 to Improve Reusability

コアポイント

    一般的なログオブジェクトインターフェイスであるPSR-3を使用すると、開発者は特定のログ実装に依存せずに再利用可能なコードを作成できるため、PHPの異なるログライブラリ間の互換性が向上します。
    • PSR-3インターフェイスは、さまざまな重大度レベルのメッセージを処理する8つの方法と、重大度レベルを受信できる一般的な
  • メソッドを提供します。その設計は、ログの実装の非互換性の問題を解決することです。 log()
    • PSR-3には多くの利点がありますが、一部のログライブラリはネイティブにサポートしていません。ただし、開発者は、アダプターモードを活用し、PSR/Logライブラリで提供される
  • クラスを拡張することにより、PSR-3準拠のアダプターを作成できます。 AbstractLogger
    • Monolog、Symfony、Moustache.phpを含む多くの主要なPHPプロジェクトがPSR-3のサポートを追加しました。コードの再利用の障壁を減らすため、より多くのライブラリとフレームワークがログを正しく使用し、開発者に有用な情報を提供することが期待されます。
    • PHP開発では、ロギングは最も一般的なタスクの1つです。ログを使用して、エラーメッセージを追跡し、重要なイベントを記録し、コードコードの問題をデバッグします。 PHPプロジェクトでは、コードには、これらの操作を処理するライブラリへの呼び出しが記載されている場合があります。残念ながら、ログライブラリへの呼び出しはコード全体に散らばっているため、コードはライブラリの可用性に依存します。これは明らかに依存関係の反転の原則に反しています。依存関係の注入を使用してオブジェクトがログライブラリにアクセスできるようにしたとしても、ログライブラリ間の違いは、それらを切り替えることが難しくかつ時間がかかる可能性があり、コードライブラリ全体の主要なリファクタリングが必要です。ログライブラリ間の互換性を向上させるために、PHP-FIGチームは最近、一般的なログオブジェクトインターフェイスであるPSR-3をリリースしました。この記事では、PSR-3が定義されたログインターフェイスで、特定のログの実装に依存しない再利用可能なコードを作成する方法について説明します。

psr-3クイックスタート

PSR-3がコードをより再利用可能にする方法を理解する前に、PSR-3とは何かを理解する必要があります。すでにPSR-3に精通している場合は、このセクションをスキップできます。仕様のコアは、オブジェクトをログするためのインターフェイスです。このインターフェイスは、異なる重大度レベルのメッセージを処理する8つの方法と、重大度レベルを受け入れる可能性のある一般的な

メソッドを開示します。 PSR-3でサポートされている8つの重大度レベルは、以下で説明するようにRFC 5424に基づいています。
  • emergency - システムは使用できません
  • alert - アクションが必要です
  • critical - 深刻な状況
  • error - 即座に注意を必要としないが監視する必要があるエラー
  • warning - 珍しいまたは望ましくないイベントですが、エラーではありません
  • notice - 通常の重要なイベント
  • info - 興味深いイベント
  • debug - デバッグの詳細

各ログメソッドは、文字列または__toString()メソッドを備えたオブジェクトでなければならないメッセージを受け入れます。追加のパラメーターは、ログメッセージのコンテキスト情報を提供できる配列を受け入れます。これらの方法とパラメーターの完全な説明は、PSR-3仕様に記載されています。

psr-3ファイルを取得

PSR -3を使用するために必要なファイルを取得するのは簡単です - PSR/Log GitHubリポジトリでそれらを見つけることができます。 Composerを使用して、これらのファイルをPackagistから取得することもできます。 PSR/ログファイルを取得するためのcomposer.jsonファイルの例を次に示します：

<code class="language-json">{
    "require": {
        "psr/log": "dev-master"
    }
}</code>

ロギングのコードの再利用を制限する方法

PHPには、それぞれがデータを収集および記録する独自の方法を備えたさまざまなログライブラリがあります。それらにはいくつかの共通点がありますが、各ライブラリには独自のロギング方法のセットがあります。これは、ログを切り替えることは困難な場合があり、多くの場合、ロギングが使用されている場所でコードを変更する必要があることがよくあります。これは、コードの再利用とオブジェクト指向の設計の確固たる原理に反します。私たちが直面している状況は、特定のログライブラリの依存関係を宣言するか、完全に記録することを避けることです。この問題をより明確に説明するには、特定の例が必要です。メールの送信を処理するシンプルなメーラーオブジェクトを作成しているとします。メールを送信するたびにメーラーにメッセージを記録してもらいたいので、優れたモノログライブラリを使用してロギングのニーズを処理することにしました。 

<code class="language-php"><?php namespace Email;

class Mailer
{
    private $logger;

    public function __construct($logger)
    {
        $this->logger = $logger;
    }

    public function sendEmail($emailAddress)
    {
        // 发送电子邮件的代码...

        // 记录消息
        $this->logger->addInfo("Email sent to $emailAddress");
    }
}</code>

次のコードでこのクラスを使用できます。

このコードを実行すると、送信された電子メールが録音され、
<code class="language-php"><?php
// 创建一个Monolog对象
$logger = new Monolog\Logger("Mail");
$logger->pushHandler(new Monolog\Handler\StreamHandler("mail.log"));

// 创建邮件发送器并发送电子邮件
$mailer = new Email\Mailer($logger);
$mailer->sendEmail("email@example.com");</code>
ファイルに新しいエントリが作成されます。この時点で、再利用可能なメーラーオブジェクトを書いたと思うかもしれません。依存関係の注入を使用して、メーラーでロガーを利用できるようにするため、メーラーコードに触れずに異なるロガー構成を交換できます。確かな原則に成功し、ハード依存関係の作成を避けたようです。ただし、アナログを使用してロギングインタラクションを処理するために、さまざまなプロジェクトでメーラークラスを再利用したいとします。アナログには

メソッドがないため、問題があります。アナログを使用して情報レベルのメッセージを記録するには、mail.logを呼び出します。以下に示すように、メーラークラスを変更してアナログメソッドを使用できます。 addInfo() Analog::log($message, Analog::INFO)

次のコードで更新されたメーラークラスを使用できます。
<code class="language-json">{
    "require": {
        "psr/log": "dev-master"
    }
}</code>

これは機能しますが、理想とはほど遠いものです。特定のロギングの実装に対するメーラーの依存に遭遇しました。これには、新しいロガーを導入するときにクラスを変更する必要があります。これにより、クラスの再利用性が低下し、特定のロガーの可用性に依存するか、クラスのログを完全に放棄するかどうかを選択する必要があります。

PSR-3を使用して、ロガーの依存関係を避けます

アレハンドロ・ゲルヴァシオがトピックに関する彼の優れた記事で説明しているように、依存関係の反転の原則は、具体的な実装ではなく抽象化に依存するべきだと言っています。ロギングの場合、私たちの現在の問題は、依存できる適切な抽象化の欠如です。これは、PSR-3が登場する場所です。 PSR-3は、ロガーに共通のインターフェイスを提供することにより、ロギング実装の非互換性を克服するように設計されています（適切に指名されたLoggerInterface）。特定の実装に縛られていないインターフェイスを提供することにより、PSR-3を使用すると、特定のロガーに依存することを避けることができます。代わりに、LoggerInterface 

<code class="language-php"><?php namespace Email;

class Mailer
{
    private $logger;

    public function __construct($logger)
    {
        $this->logger = $logger;
    }

    public function sendEmail($emailAddress)
    {
        // 发送电子邮件的代码...

        // 记录消息
        $this->logger->addInfo("Email sent to $emailAddress");
    }
}</code>
コンストラクターは

実装者を受け入れるように変更されており、LoggerInterfaceメソッドを呼び出すsendEmail()メソッドが呼び出されました。 MonologはすでにPSR-3に準拠しており、アナログはinfo()を実装するラッパーオブジェクトを提供するため、メーラークラスを変更せずにこれら2つのロガーを使用できるようになりました。モノログを使用してこのクラスを呼び出す方法は次のとおりです。 LoggerInterface

and Analog：
<code class="language-php"><?php
// 创建一个Monolog对象
$logger = new Monolog\Logger("Mail");
$logger->pushHandler(new Monolog\Handler\StreamHandler("mail.log"));

// 创建邮件发送器并发送电子邮件
$mailer = new Email\Mailer($logger);
$mailer->sendEmail("email@example.com");</code>
を使用します

メーラークラスを編集したり、使用方法を変更せずに、ライブラリでメーラーオブジェクトを使用することができます。 
<code class="language-php"><?php namespace Email;

class Mailer
{
    public function sendEmail($emailAddress)
    {
        // 发送电子邮件的代码...

        // 记录消息
        Analog::log("Email sent to $emailAddress", Analog::INFO);
    }
}</code>

PSR-3 これまでのところ、を要求する実装者を介して、特定のロギングの実装からメーラーオブジェクトを正常に分離しました。しかし、PSR-3サポートのためにまだ追加されていないロガーについてはどうでしょうか？たとえば、人気のあるKloggerライブラリはしばらく更新されておらず、現在PSR-3と互換性がありません。幸いなことに、アダプターパターンを活用することにより、Kloggerによって公開されたメソッドをで定義されたメソッドに簡単にマッピングできます。 PSR/Logリポジトリでサポートされているファイルを使用すると、拡張できるクラスを提供することにより、アダプタークラスを簡単に作成できます。抽象クラスは、

で定義された8つのレベル固有のログメソッドを一般的なLoggerInterfaceメソッドに転送するだけです。 LoggerInterfaceクラスを拡張し、独自のAbstractLoggerメソッドを定義することにより、PSR-3をネイティブにサポートしていないロガー用のPSR-3準拠のアダプターを簡単に作成できます。 Klogger用のシンプルなアダプターを作成して、これを以下に示します：LoggerInterface

<code class="language-json">{
    "require": {
        "psr/log": "dev-master"
    }
}</code>

log()メソッドは、単にLoggerInterfaceメソッドをそれぞれのKloggerメソッドにマップするだけで、Kloggerは実際のロギングアクティビティを処理します。この方法でKloggerクラスをラッピングすることにより、LoggerInterface契約を破らずに使用できます。これで、メーラークラスでKloggerアダプターを使用できます。 

<code class="language-php"><?php namespace Email;

class Mailer
{
    private $logger;

    public function __construct($logger)
    {
        $this->logger = $logger;
    }

    public function sendEmail($emailAddress)
    {
        // 发送电子邮件的代码...

        // 记录消息
        $this->logger->addInfo("Email sent to $emailAddress");
    }
}</code>
Adapterクラスを使用すると、メーラークラスを変更せずにKloggerを使用しても、

に付着することができます。 Kloggerはデバッグレベルメッセージの2番目のパラメーターを受け入れないため、アダプターを使用してもPSR-3に完全に準拠していません。 Kloggerを拡張してPSR-3と完全に互換性のあるものにすることは些細な作業ですが、それはこの記事の範囲を超えています。ただし、アダプタークラスを使用すると、完全にPSR-3に準拠することに非常に近づき、KloggerクラスでLoggerInterfaceを使用できるようになると言っても安全です。 LoggerInterface

結論 この記事では、PSR-3を使用して、特定のロギングの実装に依存しないロガーフリーコードを作成するのに役立つ方法を学びました。多くの主要なPHPプロジェクトが、Monolog、Symfony、Moustache.phpを含むPSR-3のサポートを追加しており、Drupalのような他の有名なプロジェクトでは、それを最適に統合する方法について議論しています。 PSR-3はコードの再利用の障壁を減らすため、より多くのライブラリとフレームワークがロギングを使用して、開発者に有用な情報を提供する必要があります。 PSR-3は、アプリケーションでのロギングの使用方法に影響しますか？以下のコメントセクションでお知らせください。

（フォトリアからの写真）

（スペースの制限のため、PSR-3ロギングのFAQ部分はここで省略されています。必要に応じて追加できます。

以上がPHPマスター|再利用性を向上させるために、PSR-3でロギングしますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

php symfony composer json 面向对象 构造函数 mail Error Logging 字符串 接口 对象 事件 alert github 重构
声明：
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
前の記事：PHPマスター| WAVファイルから抜粋を抽出します次の記事：PHPマスター| WAVファイルから抜粋を抽出します

関連記事

続きを見る