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.
Posts
5 comments:
That's my man :)
So what are we going to use now?
I remember first time we started using it long time ago, named application blocks at the time. It helped a lot reducing coding effort and honestly I didn't know much about enterprise level software so it was good that someone made something I can use without much thinking. Eh, well, I started thinking about it when bugs kicked in but what a heck I was just starting and everything was interesting. Anyway good we're getting rid of it.
Ah, congrats, Czechs just scored second one in the key match on the tournament, off to the second round ;)
I'm glad this entry accompanied well the match:).
It can be different from project to project. I believe question will be - "what is the value in return?".
For logging and exception handling (and trully for db access already, given whole block can have a value equal to few extension methods) I don't see any value - .NET 2.0 TraceSource with some DI incorporated just does the trick in my humble opinion.
Hi guys,
I hope that you guys are doing great.
It eventually didn't end up well for Czech Republic, I hope we'll be luckier against Italians..
About this subject, personally, I see the bottle half empty.
I see the Enterprise Library more like a set of good practices than the definitive Enterprise framework, but I think it's still good. You may be right with regards to Loggin/Exception handling saying that they don't bring any added value, but I think that overall there are still things in there that are usefull. Like the Validation Application Block, which it looks to me like a good mechanism to keep your validation rules in a single place. Or like the Data Access Block, which again in my opinion helps you to produce cleaner data access code and besides it has some capabilities like connection pooling that can be useful when leveraging .NET TranscationScope's.
Regarding configuration, yes they need separate configuration, but at least you have a good tool to nicely create and mantain that configuration. One of the things that I miss in Castle framework or Spring.NET is a GUI tool to generate configuration files or in other words pick up the interface/class from a .NET assembly instead of having to mess around with the configuration files yourself. When those configuration files get huge, the task of mantaining them become a risky business. I haven't had the chance to dig into the EL newest release, but I feel that it wouldn't be a bad idea to include Unity block in the Configuration GUI tool.
On the other hand, I agree that it may be pretentious and misleading to call that set of good practices, "Enterprise Library"...
Anyway, receive my greetings from Brussels.
Javier
Hi Javi,
Thanks and good luck with Italy on Sunday!
Nothing against EL, it is just for myself I'm going to weight twice before I decide next time to use or recommend any of the EL blocks.
I'm really not sure I'd use EL Data access anymore, because just few extension methods can achieve the same "clean" effect now with c# 3.0. As for avoiding transaction escalation from lightweight when we first encountered this issue in EL3.0 we thought first we'd implement ourselve with few lines of code, but by chance EL team came with it first in 3.1.
As for the Validation block, what I'd consider to use is a rule engine. Either WF rules engine or drools. I believe that generally it may give better separation and flexibility than coding validation rules as attributes (or custom validators). May be too heavy for some scenarios though :).
I thought there will be a breakthrough in EL4.0 for the validation block with use of Unity, but don't see any except trivial application of DI to constructing your custom validators: http://www.pnpguidance.net/Screencast/EnterpriseLibrary4ValidationApplicationBlockUnityIoCScreencast.aspx
why not consider writing a dsl for rule engine, if the matter is flexibility ?
I think validation block's purpose is different from a standart rule engine, an Entity's validity may not be always tightly coupled to the business rules i.e it can be some db constraints, or framework requirements.
The most cases when we need Entity validation through every layer,with WF or Drools is just very heavy to do basic checks such as a string is longer than its varchar correspondent in the db.
Anyway, I am happy to be at the quarter finals, sorry Stan :)
Post a Comment