EIF vs log4net
I've been doing a comparison of both products recently. Before you read, I must say that I used log4net a lot (I even appear as a contributor :o), so I may be biased. On the other hand, I only evaluated EIF, looked at how it's used in a real world product, and read the documentation provided, as well as built the examples.
Here are my conclusions.
Conventions:
· x: feature is supported equally.
· -: feature is supported/implemented, but is not as good as the other product
· +: feature is better supported/implemented than the other product
|
Feature |
EIF |
log4net |
|
General |
|
Decoupling of event source and event sink |
x |
x |
|
Arbitrary target event sinks |
x |
x |
|
Number of built-in event sinks supported |
3 |
20 |
|
Extensible |
x |
x |
|
Configuration |
-
(quite complex) |
+
(very simple) |
|
WMI supported built-in |
x |
|
|
Arbitrary log data |
+ |
-
(built-in just text) |
|
Multiple logging "domains" (ability to configure the framework by modules, i.e. each logical feature has its own config, repository and sinks) |
|
+++
(a BIG plus for highly composed and pluggable apps) |
|
Installation |
-
(mostly requires admin permissions) |
+
(xcopy) |
|
Support |
? |
x
(excelent peer support) |
|
Source provided |
|
+ |
|
Supported Platforms |
.NET |
.NET, CF, Mono, SSCLI |
|
|
|
|
|
Runtime |
|
|
|
Performance with logging enabled |
x |
x |
|
Performance with logging disabled for a certain event |
- |
++
(orders of magnitude faster) |
|
Reconfiguration |
-
(only possible with WMI or Windows Trace) |
+
(full configuration monitoring & reloading) |
|
|
|
|
|
API - Dev friendliness |
|
|
|
Event (source) categorization |
-
(uses the event Type. leads to increasingly big hierarchies of event types) |
++
(combination of log level + logger name -dotted notation-) |
|
Event source inheritance |
|
++
(filters and sinks applied to all descendant sources) |
|
Customization |
x |
+
(everything) |
|
|
|
|
One of the "distinguishing" features of EIF is request tracing, but it is mostly irrelevant as it only works using the remoting CallContext, which reduces its applicability considerably. And remoting is not a long-term platform to rely on either... For request-like tracing on a single thread (important when there're multiple components involved in an operation happening on a single machine/thread) log4net offers similar functionality through its Nested Diagnostics Context.
For business events that rely on arbitrary objects being send, EIF has a clear advantage. I wonder, however, how many business notification scenarios are actually handled through logging... Through customization similar functionality could be implemented in log4net, however.
Overall