On February 21st we've got Alex Homer coming to the Southampton user group to give us an overview of the Enterprise Library (EL) produced by the Microsoft Patterns and Practices team, so I thought I would just blog about some of my experiences of using the EL.
I first came across EL when I was working on a project developing an application lifecycle management tool in 2003, it was a green field project so we had an opportunity to use what ever technology we liked but unfortunately EL didn't exist at that time. .NET was still its early stages of development, it has come on a long way since then, and we were looking to develop the system around a plugin based architecture that give us the ability to add modules dynamically at run time. Microsoft Patterns and Practices didn't exist back then and we were just looking for any inspiration we could find, after a bit of web surfing we came across SharpDevelop an open source IDE for developing C# and VB .NET projects - essentially it was an open source Visual Studio and at the time was pretty good substitute for the .NET hobbyist, I am not sure whether project is still alive but it certainly was a life saver back in the day.
Anyway, so we had a plugin based architecture based around SharpDevelop's codon tree (see the website for more info about what a codon is!) and were merrily developing our application but it just felt like we were taking two steps forward and three steps back, hitting a brick wall at each turn trying to work out how our application should be secured, what exception handling strategy should be implemented, what model should we use for our data access, what kind of caching strategy should we implement etc I remember at the time typed datasets were the latest and greatest thing to come from Microsoft - ugh, they were horrible things and got us into all sorts of trouble.
So we seemed to bumble along for about 1 year into our project in a typical waterfall based fashion i.e. 3 months requirements capture, 3-6 months UML design, develop a "throw away prototype" whilst continuing the design, end up using the prototype to carry on development because the design wasn't "ready". It was an absolute classic and I learned a hell of a lot about how not to develop an enterprise development application, at the time it felt like the project was going nowhere and was just getting more and more stressful. I was looking for alternative ways of doing things and came across some of the early white papers produced by the patterns and practices team detailing the fact that they were developing a library of application blocks to follow industry best practice and help developers to implement basic building blocks of an application. Unfortunately, enterprise library was still a pipe dream and it was only about another year later that something useful came out and Enterprise Library 1.1 was released in January 2005.
The library contained a bunch of extensible and reusable "application blocks" designed to handle common tasks such as logging, data access, exception management and seemed to meet the exact criteria I was looking for nearly two years earlier - unfortunately the amount of re-work required to retrospectively introduce all of the application blocks into our application never quite made it passed the management team but we were able to integrate the data access, logging and caching blocks without too much trouble.
Since then the patterns and practices team continued to develop the enterprise library improving it and integrating it with changes in the .NET framework, and in January 2006 another version of the library was released that included .NET 2.0 enhancements and more improved configuration capabilities.
April 2007 saw the release of EL 3.0 with better integration with .NET 3.0 and two new application blocks including policy injection and validation and May 2007 saw some minor enhancements to these blocks. This release came with a dependency injection pipe line engine called Object Builder, although this could be used independently from the enterprise library and was used extensively in the Composite UI application block (thoroughly recommend looking at this if you are developing smart client application).
So looking back to my earlier days starting out on a green field project developing an enterprise scale application lifecycle management system, if I was to redo that project now would I use the enterprise library? Hell yeah, without a doubt, the entire library may not be relevant but I would certainly use pieces of it as a starting point.
Version 4.0 is due for release at the end of February 2008 and is going to contain a revised dependency injection block called "Unity" which is due to replace the object builder.
Well, this brief history has turned into a bit more of an epic than I thought it would, if you've made it this far, thanks for reading and hopefully see you at the next user group meeting :-).
