More than five years ago, Microsoft's patterns & practices group released the Microsoft Enterprise Library. The package contains a number of independent application blocks that provide common functionality to developers in a standardized manner. Let's explore what the Enterprise Library has in it, why you may want to use it, and how to get started.
There are nine application blocks in the package; seven of the blocks provide direct functionality, and two of the blocks are "wiring" blocks to handle architectural concerns. The nine blocks are:
- Data Access
- Dependency Injection
- Exception Handling
- Policy Injection
There are a number of benefits to this package. First, it covers many common scenarios that developers constantly write and rewrite the code for. Second, once you learn the libraries and know how to use them, you get a lot of functionality for three. Third, they are well tested and reliable. If you are writing the kind of application where you have a team of developers working on a code base (or a single developer spending more than a few weeks on the initial development), or perhaps someone is assigned the role of architect, then those are good signs that your application can benefit from this package.
The big drawback to the blocks is their complexity. The Developer's Guide is rather dense, and these are not quick fix libraries. In addition, these really are enterprise style, so they cover many more scenarios than your application may ever need to address. Finally, using the application blocks often requires you to do things in a manner radically different from what you would normally do, which makes it more difficult to bring people onto the team, and it may keep some automated tools from working correctly. For example, replacing the standard try/catch blocks with the exception handling system will make static code analysis and automatic unit test generation with a tool like Pex a lot more difficult, if not impossible.
Getting started with the Enterprise Library is a bit more complex than just downloading the bits, adding them to /bin, and putting them in a usings statement or two (though all of those steps are needed). For example, the Exception Handling block has a configuration tool to put in the appropriate code for the handlers. Once configured, you need to rewrite your code to use the blocks. Again, using Exception Handler as an example, you strategically replace try/catch blocks with calls to an instance of the Exception Handler block, which then takes care of the exceptions as per the configured policies.
If that sounds a lot more confusing than try/catch... well, it is. But the advantage is that everything you would write for stuff like logging the error is taken care of for you, and if it is something that you would be doing hundreds of times within the application, then it is a real time saver.
This is definitely a case of your mileage may vary. It has been a while since I have worked on an application that was both big enough to justify using these tools and at a stage of its development where there would have been value in using the Enterprise Library instead of other techniques or what was already in place. To really get your hands on this system, take a look at the Developer's Guide to see how to accomplish your goals.
I'd like to hear about your experiences with the Enterprise Library and any tips that you might have in using the application blocks.
Justin James is the Lead Architect for Conigent.