Sunday, June 15, 2008

What a relief - getting rid of Enterprise Library Logging/Exception handling blocks

Enterprise Library can be great to grab and use in some cases, but today I felt really relieved when eliminating the last dependency I had on its logging and exception handling blocks.
It took quite a time and effort, which will make me really cautious next time when adding/using such a dependency.

Overall not only my expectations with it have not been fulfilled for 2 years of using it, I can strongly object it having a word "Enterprise" in its name. It is just way too ambitious in my opinion given its quality and usability.

Whereas I can see how it can be used for the a new team/company (or short term project) looking for the "common standard" for logging and exception handling, I can't see a mature team/company progressing with it further.

Here are my points:

1. Way too heavy

If you have a light or base framework to deliver, it can hardly be your choice to pack together.

2. Too speculative

A lot of stuff in there I'd never use. Everything comes in one big package!

3. Ignores .NET 2.0 logging capabilities.

This is a really bad point in my opinion. Wcf is a very good sample how far you can go with .NET 2.0 built-in logging. I understand EL started with it before .NET 2.0 came, but it is not the reason for being just ignorant.

4. Has separate from .NET 2.0 configuration

Connected to point 3. Still after some point I believe it is just by all means impractical to have own set of configuration to make. Ugly as well! I want to configure it all in one place! If I want to extend it I use dependency injection, but my starting point will  be <system.diagnostics>.

5. Quality in production

This can be a long and unfair to EL team topic. I believe EL team tries to do their best with getting it right, but sorry, I've seen/fixed bugs in it that would make me now try to avoid EL on production boxes. I believe reasons for it is the authoring and budgeting model of EL. No clear way how to contribute your fixes to it, it is not "real" open source model as Spring.NET or Castle for example are.
Once I saw a message from EL team: "what would you spend $100 on EL for", I understood after some time that it was not an idiom, probably at that time $100 was the EL's budget.

6. Dependency on Unity framework

What a surprise it is a DI with EntLib own flavor!!! Whoever was serious in software development already have used DI frameworks for years. Hurray, lets abandon this and use Unity, even knowing MEF is coming that is built by core guys like Krzysztof Cwalina.
Yet another wheel invented by EL team. Arghhhh ....

There is a certain amount of controversy and unfairness above, this is what my 5 cents on it are standing for.

Post a Comment