EnterpriseLibrary 6のSemantic Logging Application Blockの感想

過去分

• EnterpriseLibrary 6のSemantic Logging Application Blockを触ってみた - かずきのBlog@hatena
• EnterpriseLibrary 6のSemantic Logging Application BlockでAzure Storageにログをはく - かずきのBlog@hatena
• Enterprise Library 6のSemantic Logging Application Block + Reactive Extensions - かずきのBlog@hatena
• Enterprise Library 6のSemantic Logging Application Blockで独自の出力先に出力する方法 - かずきのBlog@hatena

既存のロギングライブラリとの個人的な比較

Semantic Logging Application Blockを触ってみた主観的な感想になります。

ログAPIの独自実装が前提

EventSourceを継承した独自のタイプセーフなログAPIの実装が必須になります。これは、ぱっと使うには少しだけめんどくさいところではありますが、汎用的なログAPIをラップして業務アプリに特化したログAPIを作ることって結構あると思います。それなら、はじめからEventSourceクラスを継承して独自APIを作ることを前提としているSemantic Logging Application Blockって、現実的なのではないかと思います。

ログのAPI

独自実装なので、好きにできます。はい。

実装のときも、固定のパラメータはアトリビュートで指定できたりと、楽できる仕組みがそろっています。

ログ出力の設定

一般的なログイングAPIでは、構成ファイルにログの設定を記述します。これはこれでいいと思うのですが、構成ファイルで決められた内容しか制御できません。Semantic Logging Application Blockでは、ログがIOとして上がってくるので、Rxを使って柔軟にフィルタリングが出来ます。これ最高に強みだと思います。コードで柔軟に設定するのって個人的には好きです。

その他カスタマイズ可能な部分

一般的なログイングライブラリでカスタマイズ可能な、出力先やフォーマットなどは一通り独自クラスを定義することで簡単に拡張可能なようになっています。ここら辺は、普通のライブラリと一緒ですね。

まとめ

ということで、とっつきにくいと感じてたSemantic Logging Application Blockは、触ってみると意外といいやつなことがわかりました。ライブラリ好きに選んでいいという.NETの話しがあったら、ちょっと使ってみようかなと思います。