login      my ps      about      contact  



home instructor-led on-demand! screencasts blogs


Don Box's Spoutlet » IoC/DI in Indigo

IoC/DI in Indigo

Don Box's Spoutlet

Pluralsight Blogs

Syndication

Recent Posts

Tags

View more

Oslo

Archives

After reading Martin Fowler's excellent dissection of IoC and DI and Mike Spille's comparison of Spring, Hivemind, and Pico/Nano, I now think I have a handle on why Ted Neward recently asked me about IoC in Indigo (roughly 58 minutes into the interview). 
 
In Indigo, we certainly have a hierarchical set of containers (Service->ServiceInstance->ServiceContext) and each layer in the hierarchy implements a common interface for accessing "services" provided by the runtime by type (similar to System.ComponentModel.IServiceProvider).  The available "services" get populated via attributes and config (the latter not that different from NanoContainer).
 
At one point in the OM, we even had a generic Parent reference to traverse up the tree from any level (you now do it via distinctly named property at each level).
 
There are also aspects of this stuff that show up in the new config-driven database connection establishment in Whidbey.
Posted Nov 21 2004, 03:48 AM by don-box

Comments

RichB wrote re: IoC/DI in Indigo
on 11-21-2004 3:35 AM
Microsoft already have a DI language - it's called XAML.
Don Box wrote re: IoC/DI in Indigo
on 11-22-2004 8:32 AM
Rich,

XAML certainly has aspects of IoC, but it's not a slam dunk. Look for a post later this week...

DB
DanDavis wrote re: IoC/DI in Indigo
on 11-24-2004 8:53 AM
I have to shake my head over this stuff, especially the terminology. What these people are talking about has nothing to do with either "inversion" -- control is being delegated (if that), not inverted -- or "injection" -- objects are being dispensed by request, not injected. This stuff is just elaboration on Factory and Strategy patterns.
Julian wrote re: IoC/DI in Indigo
on 11-30-2004 9:31 AM
What I find strange is that in COM, Microsoft had an excellent IOC framework (complete separation of interface and implementation, with dependecies defined externally in the registry), yet they threw all those ideas out with .NET. For the last 2 years I've been designing every class in all my apps following a COM IClassFactory-style implementation of abstract factory and it's given me exceptional flexibility both in terms of upgrade/extension and testability. Why does it need the J2EE community to sell these fundamental design patterns and architectural principles back to Microsoft? don't get it!..

Add a Comment

(required)  
(optional)
(required)  
Remember Me?


home instructor-led training online training blogs

781.749.9238 (East Coast) | 310.251.9901 (West Coast) | Pluralsight, LLC , 185 Lincoln St., Suite 305, Hingham, MA 02043-1741

Copyright © 2008 Pluralsight LLC. All rights reserved.

designed by nukeation