2

最近、アプリケーション全体でログを抽象化することを検討しています。別のリソースに関するより具体的な投稿により、「共通インフラストラクチャライブラリ」が推奨されました。

http://netcommon.sourceforge.net/

具体的には、Common.Loggingクラス。これは、多数のロギング実装（log4netなど）の前に配置できる共通インターフェースを提供します。

ただし、サードパーティのコードをもう1つプロジェクトに導入するのは少し嫌です。

誰かがこのライブラリを使用しましたか？私はあなたの経験を聞いてみたいと思います。

ありがとう

4

4 に答える 4

4

log4netでCommonInfrastructureLibraryを使用しましたが、うまく機能しました。クライアントがMicrosoftのエンタープライズライブラリ（EntLib）ロギングを使用する可能性を開いたままにしておきたいと表明したため、log4netだけでなくそれを使用しました。

ブラッドブルースがこの抽象化レイヤーの使用を勧めない理由はわかりません。使用するのは簡単で、問題は発生しませんでした。IMO log4netは、他のどの製品よりも優れていますが、Microsoftスタンプの快適性が追加されているという理由だけで、EntLibを望んでいる人もいます。抽象化レイヤーを使用することで、コードを変更したり再コンパイルしたりせずに、構成ファイルを変更するだけで、クライアントがEntLibに自由に切り替えることができます。

于 2009-08-18T11:23:43.500 に答える
1

上記のロギングプロジェクトを切り替える予定ですか？

リストされているロギングプロジェクトの1つを使用している可能性があり、使用していない誰かにソースを配布していますか？

  1. Common.Loggingでサポートされているものよりもはるかに多くのロギングプロジェクトがあります
  2. これは、ODBCが何年も前に行ったのとよく似ているようです。互換性があるものとして販売されていますが、1つのプロバイダー固有の機能を使用するとすぐに、切り替えることができなくなります。
  3. ロギングで問題が発生した場合、デバッグする2つのレイヤーがあります。

また; ライブラリを切り替える予定がない場合は、Common.Loggingクラスを使用しません。

于 2009-08-18T10:55:08.970 に答える
1

簡単なフォローアップとして...今日はロギングキックをしていて、アプリのログをリアルタイムで表示できるようにチェーンソーを機能させることにしました。しかし、チェーンソーでUdpReceiverを動作させることができませんでした。

解決策は、Chainsawを忘れて、（Common.Logging構成設定を介して）NLogを有効にし、代わりにNLogViewerを使用することでした。NLogとNLogViewerはアドバタイズされたとおりに連携し、ログを発生時に表示できるようになりました。コードベースを1ビット変更することなく、NLogをアプリに組み込むことができました。Common.Loggingの抽象化を含めることの見返りは、私が予想していたよりもはるかに早く来ました。

于 2009-12-20T04:12:09.730 に答える
0

MVCアプリでlog4netを利用し始めたとき、コントローラークラスと具体的なlog4net実装との緊密な結合について懸念するようになりました。Common.Logging（偶然にもlog4netのインターフェースを反映している）で定義されている特定のインターフェースにコミットするのは事実です。コミットメント。しかし、Common.Loggingの2.0リリースでは、すぐに抽象化が可能になり、それが模倣するlog4netインターフェースは、バトルテスト済みで使いやすいものになっています。また、参照を追加してWeb.configファイルを更新するだけで、さまざまな具体的なロギング実装を使用、テスト、および実験できるというアイデアが気に入っています。

ブルースのポイントはすべて完全に有効です。抽象化は単なる誤った安心感に過ぎず、決定は私を尻に食い込ませることになりかねません。それでも、ベスタープラクティスが登場するまで、ベストプラクティスの側で誤りを犯さなければならない場合があります。:-)

于 2009-12-19T21:33:23.277 に答える