PHPマスター|再利用性を向上させるために、PSR-3でロギングします
コアポイント
-
一般的なログオブジェクトインターフェイスである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に精通している場合は、このセクションをスキップできます。仕様のコアは、オブジェクトをログするためのインターフェイスです。このインターフェイスは、異なる重大度レベルのメッセージを処理する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
ファイルの例を次に示します:
{ "require": { "psr/log": "dev-master" } }
ロギングのコードの再利用を制限する方法
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"); } }
次のコードでこのクラスを使用できます。
このコードを実行すると、送信された電子メールが録音され、<?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");
メソッドがないため、問題があります。アナログを使用して情報レベルのメッセージを記録するには、mail.log
を呼び出します。以下に示すように、メーラークラスを変更してアナログメソッドを使用できます。 addInfo()
Analog::log($message, Analog::INFO)
{ "require": { "psr/log": "dev-master" } }
これは機能しますが、理想とはほど遠いものです。特定のロギングの実装に対するメーラーの依存に遭遇しました。これには、新しいロガーを導入するときにクラスを変更する必要があります。これにより、クラスの再利用性が低下し、特定のロガーの可用性に依存するか、クラスのログを完全に放棄するかどうかを選択する必要があります。
PSR-3を使用して、ロガーの依存関係を避けます
アレハンドロ・ゲルヴァシオがトピックに関する彼の優れた記事で説明しているように、依存関係の反転の原則は、具体的な実装ではなく抽象化に依存するべきだと言っています。ロギングの場合、私たちの現在の問題は、依存できる適切な抽象化の欠如です。これは、PSR-3が登場する場所です。 PSR-3は、ロガーに共通のインターフェイスを提供することにより、ロギング実装の非互換性を克服するように設計されています(適切に指名されたLoggerInterface
)。特定の実装に縛られていないインターフェイスを提供することにより、PSR-3を使用すると、特定のロガーに依存することを避けることができます。代わりに、
<?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"); } }
実装者を受け入れるように変更されており、sendEmail()
メソッドが呼び出されました。 MonologはすでにPSR-3に準拠しており、アナログはinfo()
を実装するラッパーオブジェクトを提供するため、メーラークラスを変更せずにこれら2つのロガーを使用できるようになりました。モノログを使用してこのクラスを呼び出す方法は次のとおりです。
LoggerInterface
<?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");
メーラークラスを編集したり、使用方法を変更せずに、ライブラリでメーラーオブジェクトを使用することができます。
<?php namespace Email; class Mailer { public function sendEmail($emailAddress) { // 发送电子邮件的代码... // 记录消息 Analog::log("Email sent to $emailAddress", Analog::INFO); } }
これまでのところ、を要求する実装者を介して、特定のロギングの実装からメーラーオブジェクトを正常に分離しました。しかし、PSR-3サポートのためにまだ追加されていないロガーについてはどうでしょうか?たとえば、人気のあるKloggerライブラリはしばらく更新されておらず、現在PSR-3と互換性がありません。幸いなことに、アダプターパターンを活用することにより、Kloggerによって公開されたメソッドをで定義されたメソッドに簡単にマッピングできます。 PSR/Logリポジトリでサポートされているファイルを使用すると、拡張できる
クラスを提供することにより、アダプタークラスを簡単に作成できます。抽象クラスは、で定義された8つのレベル固有のログメソッドを一般的なLoggerInterface
メソッドに転送するだけです。 LoggerInterface
クラスを拡張し、独自のAbstractLogger
メソッドを定義することにより、PSR-3をネイティブにサポートしていないロガー用のPSR-3準拠のアダプターを簡単に作成できます。 Klogger用のシンプルなアダプターを作成して、これを以下に示します:LoggerInterface
{ "require": { "psr/log": "dev-master" } }
log()
メソッドは、単にLoggerInterface
メソッドをそれぞれのKloggerメソッドにマップするだけで、Kloggerは実際のロギングアクティビティを処理します。この方法でKloggerクラスをラッピングすることにより、LoggerInterface
契約を破らずに使用できます。これで、メーラークラスでKloggerアダプターを使用できます。
<?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"); } }
に付着することができます。 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 サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











JWTは、JSONに基づくオープン標準であり、主にアイデンティティ認証と情報交換のために、当事者間で情報を安全に送信するために使用されます。 1。JWTは、ヘッダー、ペイロード、署名の3つの部分で構成されています。 2。JWTの実用的な原則には、JWTの生成、JWTの検証、ペイロードの解析という3つのステップが含まれます。 3. PHPでの認証にJWTを使用する場合、JWTを生成および検証でき、ユーザーの役割と許可情報を高度な使用に含めることができます。 4.一般的なエラーには、署名検証障害、トークンの有効期限、およびペイロードが大きくなります。デバッグスキルには、デバッグツールの使用とロギングが含まれます。 5.パフォーマンスの最適化とベストプラクティスには、適切な署名アルゴリズムの使用、有効期間を合理的に設定することが含まれます。

セッションハイジャックは、次の手順で達成できます。1。セッションIDを取得します。2。セッションIDを使用します。3。セッションをアクティブに保ちます。 PHPでのセッションハイジャックを防ぐための方法には次のものが含まれます。1。セッション_regenerate_id()関数を使用して、セッションIDを再生します。2。データベースを介してストアセッションデータを3。

PHP開発における固体原理の適用には、次のものが含まれます。1。単一責任原則(SRP):各クラスは1つの機能のみを担当します。 2。オープンおよびクローズ原理(OCP):変更は、変更ではなく拡張によって達成されます。 3。Lischの代替原則(LSP):サブクラスは、プログラムの精度に影響を与えることなく、基本クラスを置き換えることができます。 4。インターフェイス分離原理(ISP):依存関係や未使用の方法を避けるために、細粒インターフェイスを使用します。 5。依存関係の反転原理(DIP):高レベルのモジュールと低レベルのモジュールは抽象化に依存し、依存関係噴射を通じて実装されます。

phpstormでCLIモードをデバッグする方法は? PHPStormで開発するときは、PHPをコマンドラインインターフェイス(CLI)モードでデバッグする必要がある場合があります。

記事では、入力検証、認証、定期的な更新など、脆弱性から保護するためのフレームワークの重要なセキュリティ機能について説明します。

システムが再起動した後、UnixSocketの権限を自動的に設定する方法。システムが再起動するたびに、UnixSocketの許可を変更するために次のコマンドを実行する必要があります:sudo ...

静的結合(静的::) PHPで後期静的結合(LSB)を実装し、クラスを定義するのではなく、静的コンテキストで呼び出しクラスを参照できるようにします。 1)解析プロセスは実行時に実行されます。2)継承関係のコールクラスを検索します。3)パフォーマンスオーバーヘッドをもたらす可能性があります。
