Enterprise Library - Library or Framework?
I've been using the Enterprise Library (now 3.1 and significantly more "mature") for a bit now, and on the whole I like what's been done. Policy injection is very AOP-ish and clean (especially with 3.1, you have more freedom to customize) , Logging and Data are provider agnostic (in fact, Ken Scott beat me to it and did a very nice SQLite provider that you can find on the Codeplex extensions bits for EntLib) -- and there are other features that help with the whole concept of "lets build our apps around this".
However, Brad Wilson makes some good points - namely, that "if there is any single failing of Enterprise Library, it is where it tries to behave like a framework where it should instead be acting like a library. Baking the configuration system into EntLib and making it hard to use without it is the most obvious example of this behavior."
I feel the jury is out on this, because if you really want to "engage" with this type of "best practices" concept, at some point, you are going to have to "buy in" to the way it is used, and that means basically, that -- framework or library regardless -- you need to make the business decision of whether you feel you are ready to "bake" all the configuration crap into your apps. Oh, and please don't remind me that I can use the VS.NET integration "Configuration Tool" for this, because it's a piece of junk. I do it manually - I use Reflector to get the assembly data that needs to go into the configuration entries.
While it is certainly possible to use the best practices ideas to attempt to retrofit the Framework "stuff" and backport it into a more-or-less "Library" (e.g. Log4net, NHibernate) type of concept, it would still take a lot of work. My point is that if you decide you want to use this you need to decide to either accept the way its been engineered and use it, or do something else. Bitching isn't going to help much at this late stage of the process.
A lot of this revolves around the strategic decision to use the ObjectBuilder infrastructure to "glue" everything together for the EntLib and related CAB frameworks (Reflection caching and so on) and to try and disassociate this from the dependencies that got baked into earlier versions. Scott Densmore provides more depth on this.
Whatever the end result, it is obvious to me that this whole effort still represents an evolutionary process and that there may be more and different approaches to this whole CAB / Entlib concept forthcoming. However, at this point I feel comfortable with the idea that I can use this the way it is, without fear that I am going to be blown away by some new breaking "innovations" in the future. My point is, take a look. Nobody is holding a gun to your head. If it doesn't fit, then aquit!
In the meantime, developers (IMHO) should take note of the fact that the Entlib as it currently stands is eminently usable, and in fact I am currently doing work for a major client which uses the Entlib 3.0 / 3.1 as an integral part of our work. Everthing can be made to "fit", you can build business and data layers over it, and there seems to be a vibrant community that's evolved over the EntLib / CAB concepts and it's started to take a life of its own. I mean, if you want to see an EntLib evangelist, look at David Hayden. This guy's got Entlib growing out of his ears!
And, you know what? If its good enough for David, then I'm fine with it!
EntLib. It's not just for breakfast anymore.
However, Brad Wilson makes some good points - namely, that "if there is any single failing of Enterprise Library, it is where it tries to behave like a framework where it should instead be acting like a library. Baking the configuration system into EntLib and making it hard to use without it is the most obvious example of this behavior."
I feel the jury is out on this, because if you really want to "engage" with this type of "best practices" concept, at some point, you are going to have to "buy in" to the way it is used, and that means basically, that -- framework or library regardless -- you need to make the business decision of whether you feel you are ready to "bake" all the configuration crap into your apps. Oh, and please don't remind me that I can use the VS.NET integration "Configuration Tool" for this, because it's a piece of junk. I do it manually - I use Reflector to get the assembly data that needs to go into the configuration entries.
While it is certainly possible to use the best practices ideas to attempt to retrofit the Framework "stuff" and backport it into a more-or-less "Library" (e.g. Log4net, NHibernate) type of concept, it would still take a lot of work. My point is that if you decide you want to use this you need to decide to either accept the way its been engineered and use it, or do something else. Bitching isn't going to help much at this late stage of the process.
A lot of this revolves around the strategic decision to use the ObjectBuilder infrastructure to "glue" everything together for the EntLib and related CAB frameworks (Reflection caching and so on) and to try and disassociate this from the dependencies that got baked into earlier versions. Scott Densmore provides more depth on this.
Whatever the end result, it is obvious to me that this whole effort still represents an evolutionary process and that there may be more and different approaches to this whole CAB / Entlib concept forthcoming. However, at this point I feel comfortable with the idea that I can use this the way it is, without fear that I am going to be blown away by some new breaking "innovations" in the future. My point is, take a look. Nobody is holding a gun to your head. If it doesn't fit, then aquit!
In the meantime, developers (IMHO) should take note of the fact that the Entlib as it currently stands is eminently usable, and in fact I am currently doing work for a major client which uses the Entlib 3.0 / 3.1 as an integral part of our work. Everthing can be made to "fit", you can build business and data layers over it, and there seems to be a vibrant community that's evolved over the EntLib / CAB concepts and it's started to take a life of its own. I mean, if you want to see an EntLib evangelist, look at David Hayden. This guy's got Entlib growing out of his ears!
And, you know what? If its good enough for David, then I'm fine with it!
EntLib. It's not just for breakfast anymore.
Comments
Post a Comment