Making Dependency Injection Simpler in EntLib 4
The benefits of modular design with cohesive components that have little or no coupling to the rest of the software system are commonly recognized today. Dependency injection is a mechanism that facilitates such aggressive decoupling and independence of components. Lightweight dependency injection containers (such as StructureMap, Spring.NET, or Castle Windsor) help assemble components (potentially from different projects) into a cohesive application at runtime and promote code reuse. An introduction to dependency injection can be found in this article by Martin Fowler.
The values of modular design implemented with support of dependency injection have been long recognized and embraced by Microsoft patterns & practices. Originally, implemented for the Composite UI Application Block (CAB) and later for the Enterprise Library v2 (back in early 2006), the ObjectBuilder pipeline allows to customize how objects are created at runtime. The current Enterprise Library configuration system is based on a DI container created using ObjectBuilder (Brian Button has written an excellent post on how Enterprise Library used ObjectBuilder).
With the upcoming version of EntLib (v4), we are planning to provide containers (flat and hierarchical) that will support dependency injection out of the box. These containers will be packaged individually and also with EntLib v4. Furthermore, to demonstrate the effective use of dependency injection on a real world project, we plan to refactor individual EntLib blocks and abstract away configuration code (configurators). We will build an EntLib façade that will have individual configurators injected in it as needed. A client app can go through this façade to request services while all wiring of objects necessary for those services to run will be handled by the DI container. This will not only make the design cleaner but will also make it easier to use and configure only those application blocks that you desire.
Once refactored, the EntLib blocks can be used as a la carte with other DI containers – some updating of the façade would be necessary and we invite the EntLib enthusiasts to port the EntLib façade to individual containers. Swapping DI containers means organizations can leverage their existing infrastructure.
For those who wish to continue to use the EntLib the way they always had, the current public API of EntLib will NOT be broken.
We believe that these changes will not only add well-desired functionality to the list of p&p assets, but further promote the principles of good architectural design.
Of course, we’d like to hear from you: comments, ideas, screams….