Tom Hollander has written a long article on why getting the EL ready for .NET 2.0 is turning out to be a pain. As a strong supporter of what the patterns & practices group is doing, I’ve been reluctant to weigh in on this topic. However, as time goes by, I feel more and more compelled to say something.
It’s my opinion (and my opinion only) that the EL is taking the wrong direction. It’s this direction that is causing the significant and unnecessary delays. There were quite a few problems with the Application Blocks, which were the previous attempts to help .NET developers. The most significant were the lack of cohesion between the blocks and lack of symmetry. They didn’t fit well together and they didn’t work the same way. If you were using multiple blocks, this made setting them up and getting them to work a pain.
The Enterprise Library was born out of this pain. It was an attempt to bring all (or most) of the Application Blocks together in one complete package. All of the blocks would retrieve their configuration information the same way, and work together seamlessly. Sounds great. And it’s a great idea. It’s been the implementation of this idea that has suffered.
Why? Because the EL is HUGE. It’s gone the other way in difficulty to set up and use. Sure, all the blocks work together well and are set up the same way, but understanding how they’re set up and extending the blocks or writing your own has become cumbersome to the extreme. This also means that making a significant change to the core of the blocks, like getting them to work with .NET 2.0, is a very big deal.
There’s another problem with the EL. It’s Open Source and it isn’t. Tom and Scott and the team are working very hard to get this running and should be commended. But why can’t I contribute code to it and help speed up the effort? Why can’t you? It’s very frustrating as a user that desperately wants to use the product and has worked extensively with it and the Application Blocks. I think part of the reason why development hasn’t been opened up is what I specified in the previous paragraph. It’s huge and intertwined and it’s very easy to make breaking changes at the moment.
Me, I prefer simplicity. I think the EL should be set up as follows. There should be a versioned Core block and a Configuration block. All of the other blocks should work with these two blocks and should require specific versions (or later) to work. New versions of these blocks must be backwards compatible with previous version wherever possible. If Tom and Scott want to control the development of these two blocks, then that would probably be acceptable.
However, the other blocks such as Data Access, Exception Handling, Logging, Caching, etc., should be much more of Open Source projects. Development would be faster, and it’d be much easier for me to pick and choose what blocks I want to use or extend the ones I want to use. If I have a Data Access block that requires version 3 of the core and I have a Logging block that requires version 4 of the core, then I just need to make sure I have version 4, and everybody should be happy. With independent releases, we get much faster turnaround time on most of the blocks, because we’re not waiting on a complete feature set, but rather the feature set required for the block.
Yes, there are issues with such a proposal. But they seem to be manageable to me, and it seems to me that this type of plan would greatly benefit developers and MS alike.