ロガーを利用するための最もまとまりのある場所は何ですか？

Question

Javaを使用してタスクマネージャープログラムを作成し、Swingの瞬間に1つのUI実装を作成しました。プログラムには現在3つのレイヤーがあります。ユースケースコントローラーを介してドメインレイヤーと相互作用するプレゼンテーションレイヤー、最後に永続に使用される技術サービスレイヤー。タスクの追加、タスクのステータスの編集など、この時点でユーザーが取ることができるいくつかのアクションがあります...このスキームの私のロガーの目的は、ユーザーが取ったすべてのアクションを追跡することです。そのため、コマンドを書くためにロガーを呼び出すことができる場所がいくつかあります。これはひどいデザインの決定であるため、プレゼンテーションレイヤーに記録することはありません。したがって、コントローラー、コマンドインターフェイス（UNDO/REDO関数を実装する目的ですべてのコマンドの実行を処理するように実装されています。 ）、または実際に操作されている低レベルのクラスでは、たとえばタスククラスを言います。

コントローラーは、UIレイヤーとドメインの間の接触点として機能するため、これには比較的適切なオプションだと思います。したがって、すべての注目すべきコマンドは最終的にコントローラーを通過し、すべての重要な方法が記録されていることを簡単に確認できることを確認します。 。コントローラーでそれを行わない理由は、それが凝集を減らし、結合を増加させ、肥大化したコントローラーにつながる可能性があることです。

具体的なコマンドは、ロギングに必要なすべての情報も持っているため、別の潜在的な場所です。これにより、コマンドの結束力が低下し、結合が増加します。また、ロギングを失うよりも、ドメインオブジェクトでアクションを実行するためにコマンドインターフェイスを使用しない場合。

最後に、これにより、ロガーを下位レベルのドメインオブジェクトメソッドに実装することになります。これは、プログラムが使用されており、必要なすべての情報が利用可能な場合、ロギングが常に発生するため、良い候補です。唯一の負の部分は、ロガーコマンドが低レベルのドメインオブジェクトの間にまばらに散らばっており、適切な方法がすべて記録されていることを確認するのが難しくなることです。

このタイプの決定について議論をして、あなたのすべてのコメントに感謝します。

Answer 1

最初に実用性について考えてください。多くの場合、ロギングはメンテナンスおよび管理上の懸念事項です。デザインの各レイヤーは、ロギングの候補ですが、多少異なる理由です。

あなたのオブジェクトの階層とデザインを本当に知らずに...

ドメインからUIに移動すると、各レイヤーは前のレイヤーの抽象化または動作の収集です。あなたはあなたが探している粒度のレベルのようなことを自問する必要がありますか？コマンドのロギングを見ると便利ですか？また、関連するドメインレイヤーコールごとにロギングを確認すると便利ですか？ドメイン呼び出しを解読して特定のコマンドに関連付けるのは必ずしも簡単ではないかもしれません。