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….
Comments
Anonymous
December 03, 2007
PingBack from http://msdnrss.thecoderblogs.com/2007/12/03/making-dependency-injection-simpler-in-entlib-4/Anonymous
December 04, 2007
Hello Grigori. Is there a timeframe for EntLib 4?Anonymous
December 04, 2007
Gabriel, at the end of February - March 2008. BTW, you can see all p&p upcoming releases here: http://msdn2.microsoft.com/en-us/practices/bb232643.aspx GrigoriAnonymous
December 05, 2007
Enterprise Library 4.0 Tom Hollander's blog has just release a post about Dependency Injection comingAnonymous
December 12, 2007
In case you've missed it, Grigori Melnik has announced that the forthcoming version of the EntLibAnonymous
December 14, 2007
Grigori, My name is Gael Fraiteur, I am the author of PostSharp (http://www.postsharp.org) and PostSharp4EntLib (part of EntLibContrib). Maybe Olaf told you about me. I'm excited about DI features in the next Ent Lib. I'm looking forward to extend PostSharp4EntLib to support dependency injection. One of the things where PostSharp can help is the transformation of object constructors to inject dependencies automatically, without the need of reflection or special constructors. In the Java environment, AspectJ is commonly used conjointly with the Spring framework; PostSharp intends to play a similar role than AspectJ in .NET. I would love if EntLib could offer the necessary extension points, and eventually, if you find it usefull, I offer my help for early design review and testing. I'm looking forward to cooperating in this release and its companion EntLibContrib! Gael P.S. I live in the region of Melnik, Czech Republic. www.melnik.cz :)Anonymous
December 19, 2007
Hello Grigori, At our company we use ObjectBuilder extensively, and significantly expanded its functionality. IIRC, we started off with something like http://www.codeproject.com/KB/cs/object_builder.aspx example, but significantly expanded it to include remoting objects, constants, and array parameters. By the way, there is a bug in ObjectBuilder, still present in 3.1 (I couldn't find where to post it otherwise): In Guard class, TypeIsAssignableFromType() incorrectly fails when providedType is MarshalByRefObject, and the assignee is some interface or a class. Replacing if (!assignee.IsAssignableFrom(providedType)) with if (!assignee.IsAssignableFrom(providedType) && providedType != typeof(MarshalByRefObject)) fixes the problem. This bug happens when a remoting object is created with a custom policy, and used as a constructor parameter to some other object. Thanks!Anonymous
December 19, 2007
Discovered one more bug in ObjectBuilder: in BuilderStrategy.cs, ParametersToTypeList() throws NullRef exception if a parameter is null: need to replace types.Add(parameter.GetType().Name); with types.Add(parameter == null ? "null" : parameter.GetType().Name); Is there a good place to file such bugs?Anonymous
December 27, 2007
I think dependency injection is a nice to have, but I think more important, and something that has been missing from P&P is proper use (the practices part) of dependency injection, IoC, or whatever you'd like to call it, in detail. It's not a new concept, and you can find traces and flavors of it in the core .NET framework (encryption classes come to mind), but I work with a company that this type of architecture is just speculative generalities (Martin Fowler) and has done nothing but increase the TCO through the cost of maintenance and added features. Endless 'what if' scenarios are not part of what we need to be writing for, just solving business problems and accomplishing the flexibility we need for the next 3-5 years. Obviously no one here is going to argue the fact that you should have a good design and enterprise architecture in place before embarking on any sort of project, but the sad truth is that many ITS shops don't, or have a very weak one, and all too often the so called architects jump right on the latest thing when it may not be the best bet. My request is that as you do this, and future endevours (and possibly doing it in retrospect on past ones), that you take the time to point out (at the beginning of the documentation, since nobody reads past the first page or two), the CONS of using a particular portion of EL (or any other P&P tool) and when it's a BAD idea to use one. I think this will greatly help myself and others like me who constantly battle with people on the 'yes that's a great idea, but...' front in ITS shops and the like.Anonymous
December 27, 2007
bri189a, I agree with your posting and that's why the documentation on the appropriate scenarios for using DI and other blocks of EntLib is a priority 1 story for us going forward with v4. Thanks for your comment! GrigoriAnonymous
December 27, 2007
Yurik, hello, Many thanks for your bug reports. We'll look into these for sure. As a side note, the best place for posting bug reports is in the Issue Tracker on codeplex (http://www.codeplex.com/entlib/WorkItem/List.aspx) -no need to repost, just for the future reference. Cheers, GrigoriAnonymous
January 08, 2008
Grigori, I've heard that the new container to be provided is being referred to as the Dependency Injection Application Block. If so, shouldn't this really be called the Inversion of Control Application Block? The inverse of the Martin's premise for using the term DI would seem to apply here. As frameworks which only invert the process of obtaining dependencies are more descriptively referred to as performing DI, frameworks which provide other forms of inversion are more descriptively referred to as IoC. Examples of this would include the auto-wiring of events and auto-registration of services within the Composite UI Application Block. DerekAnonymous
January 08, 2008
I've posted the current EntLib4 product backlog on Codeplex: http://www.codeplex.com/entlib/Wiki/View.aspx?title=EntLib4%20BacklogAnonymous
January 08, 2008
I've posted the current EntLib4 product backlog on Codeplex: http://www.codeplex.com/entlib/Wiki