私のソフトウェアはレイヤーにあり、各レイヤー間に明確に定義されたAPIがあります。私は最初からこれらのAPIのロギングを実装する傾向があるため、特定のトランザクションについて、基礎となる各レイヤーでAPI呼び出しがどのように発生するかを確認できます。間違いがある場合は、特定のレイヤーに絞り込むのに役立ちます。層。ロギングは、問題の原因となった以前のすべての通常のアクティビティのログを表示することにより、問題を再現するのにも役立ちます。
また、可能な場合は各レイヤー内にアサーションを追加し、アサーションの失敗をログに記録します。
したがって、ログファイルには、パブリックAPIへの一連の呼び出しが示され、内部からエラーメッセージが生成されることがよくあります。これは、多くの場合、問題を診断するのに十分です。
それを超えて、必要に応じてデバッグレベルのログを追加します。開発中および/またはリリース後に特定の問題をデバッグするためです。
ロギングを気にする私の理由は、以下で部分的に説明されています。
リリースされたソフトウェアのバグを修正するために、私はログファイルに依存しています。また、開発中のソフトウェアについても同じことがよくあります。
あなたが言った、
ICakeRepositoryの実装など、低レベルのクラスをロガーのもので飾ることはめったにありません。それは無意味に思えます。
私は言った、
私のソフトウェアはレイヤーにあり、各レイヤー間に明確に定義されたAPIがあります。私は最初からそれらのAPIのロギングを実装する傾向があります...
私が「レイヤー」とは何を意味するのかを説明したほうがいいと思います。これは、「下位レベル」のクラスと同じである場合とそうでない場合があります。
たとえば、私のシステムには次のレイヤーがある場合があります。
- UI
- ビジネスレイヤー（データ操作のルール）
- データアクセス層（データベースI / O用）
- データベース
その場合、次のインターフェースまたはAPIがあり、ロギングに値する可能性があります。
- ユーザーとUIの間（つまり、UIイベント、マウス、キーボード）
- UIとビジネスレイヤーの間（「控えめなダイアログボックス」を参照）
- ビジネスレイヤーとDALの間
- DALとデータベースの間
あるいは、システムは2つのピアエンドポイントを接続するコンポーネントのチェーンである場合があります（「トップ」レイヤーと「ボトム」レイヤーはそれほど明確ではありません）。
いずれにせよ、私がログに記録しているのは、各コンポーネントのパブリックファサードであるAPIです。これは、いくつかの理由でログに記録するのに適しています。
- それほど複雑ではありません（ファサードは、基盤となる/内部実装よりも単純になる傾向があります）
- 良好なカバレッジ（ファサード全体をログに記録し、コンポーネントに入る唯一の方法がファサードを経由する場合、コンポーネントに入るすべてのものをログに記録したことがわかります）
- コンウェイの法則とうまく連携します。それぞれが異なるチームによって開発された複数のコンポーネントでシステムをデバッグする場合、よくある質問の1つは、「どのコンポーネントに障害があるので、どのチームがデバッグする必要があるか」です。