4

現在、(Asp.Net Web Api) アプリケーションでログ記録を設定しているので、ログ記録によるベスト プラクティスについて読んでいました。ロギングのベスト プラクティスに関するこの質問にたどり着きました。

私はNinject-> Logging Extensions->のNlog / Log4Net方向に進んでいましたが、この質問 (または答えと言うべきか) は、もう一度考えさせられました。

現時点では、トレースを有効にして、あちこちでログを記録していますが、ログとトレースが合計されないのは少し面倒です。

診断トレースに切り替えて、フレームワークが既に提供しているものの上に構築すると、より完全なトレースになると思います。完全なストーリーを伝えるトレースは、ストーリーの一部を知っている個別のトレースとログよりも有用に思えます。そしてもちろん、リスナーとフィルターを使用して、いつでも物事を再び分離することができました。

しかし一方で、私は常に次のことを学びました。

ロギング != トレース

ですから、これは私に疑問を残します.ロギングフレームワークをやめるべきですか、それはプロジェクトの開始段階ですか、それともそのままにしておくべきですか?

また、ロギング フレームワークを削除した場合、別のロギング/トレース フレームワークに再度切り替えたい場合に備えて、インターフェイスを使用する必要がありますか?それとも、System.Diagnostics に依存させることができますか?

4

1 に答える 1

7

Log4NET パスを試し、Ninject を調べました。

私が見つけたものから、Diagnotisics.Trace をログ フレームワークに変換することは、私が見つけたログ フレームワークの重みに対処しようとするよりもはるかに生産的であると言えます。(そして、Trace != Logging に同意します)

おそらく私はコントロール マニアですが、コード ベースに大量の意見を取り入れたくありません。拘束具じゃなくて道具が欲しい。

Trace をロギング フレームワークに構築するには少し作業が必要ですが、これはコア診断 dll であるため、再利用性が非常に高くなります。

とにかく、私の意見ですが、Diagnostics.Trace ルートの方がずっと好きです。http://www.codeproject.com/Articles/2680/Writing-custom-NET-trace-listeners - 古いものですが、独自のものを作成するために必要なものを示します。

于 2013-05-03T22:21:47.937 に答える