Jeremy D. Miller -- The Shade Tree Developer

Hear, hear!!!

Amen to that. If MS rejects the idea, or drags their feet, would a neutral open source project or organization providing a set of interfaces serve as a stand-in? Any chance something like that could gain critical mass? I think that in addition to IoC there are a small handful of other interfaces that could provide framework or infrastructure tool developers with the same benefit, like logging.

Absolutely, Jeremy, well said. While I naturally want to use Ninject, I'm happy using other DI frameworks as well. I just don't think that infrastructure libraries should be opinionated, because you might end up being forced to put two DI frameworks in the same project.

If this doesn't end up in MEF, maybe we should consider something like the AOP Alliance? I'd be willing to add it to Ninject, even if it means creating an external dependency. As long as the dependency was tiny, it would be worth it. That way framework developers could work against the common abstraction rather than creating their own custom abstractions each time.

Isn't someone going to make the ridiculous "we already have a locator, and it's IServiceProvider" claim?

@Jimmy,

Not good enough, not by half.

IServiceProvider only gives you a tiny bit. There is a lot that we need to create first.

Note, MonoRail has no dependency on Windsor

That was my next note, we just completed a project that used StructureMap w/ MonoRail, just fine.  When you're back in town, I can show you what we came up with.

@Ayende

Ha, that was *supposed* to be a joke.  I had a colleague that would bring IServiceProvider up constantly as some kind of locator panacea.  I think he works at Arby's now...

Thanks for taking notice of the session!

The session started out small, with just three of us, and finished with seven or eight. We didn't have anyone on-hand with direct experience with developing a framework with this kind of IoC dependency-and-yet-abstraction, so the core nugget for the session was reasonably addressed* and out of the way relatively early. That did, however, afford us the opportunity to expand the discussions out into a number of interesting directions more or less related to the original subject, in the end touching on everything from AOP to introducing IoC to teams to selling TDD and BDD to management above and team members below.

You can check out my rough notes from the session, written up from memory during the two sessions since the IoC session this morning, here:

www.altnetpedia.com/Calgary200808FrameworkIoC.ashx

If anyone has any comments or questions, I'll try to keep an eye on this post for a while, but if I miss anything feel free to mail me at jeremy@jeremygray.ca.

* As for addressing the core subject during the session, the lowest common denominator (at least, the one that this framework needs) is captured in the notes (I think ;) but summarized thusly:

- Service Locator, with support for resolution of both default and named instances of a given type

- ctor DI with auto-wiring

- a convention-based scanner, either built in or created while integrating the container with the application framework, that supports the conventions we will define. (It will be a basic pattern along the lines of "If IFoo refines IComponent, a discovered class Foo that implements IFoo is registered as the default implementation of IFoo, where any IFoo-implementing XFoo, YFoo, etc. are registered as named IFoo implementations called "X", "Y", etc. respectively.

Shouldn't at least one of those signatures be

object GetInstance(Type t, string name);

There are many situations when I don't know the type at compile time. Also, we might need...

object GetInstance(string name)?

For instance, when doing interop with a DLR language, I might not have a type *at all* that I can pass.

@Haacked - We do need a get that is by some kind of name key, and that one is already the list I posted as "Service Locator, with support for resolution of both default and named instances..."

As for passing the type as an argument, I'm not entirely against your suggestion but do really wonder how it is you would expect to interact with the located service if you didn't have at least know some type information available. I tend to work entirely in static typing territory, however, so I would certainly understand that the requirements over in dynamic territory might be more than a bit different. ;)

Pingback from  ASP.NET MVC Archived Blog Posts, Page 1

@Jeremy M, Jeremy G, et al:

I would push strongly for the whole "if you follow DI seriously, you won't need service locator stuff"

At least in Fluent NHibernate, the ObjectFactory.GetInstance<> calls were all unnecessary and served only to keep some of the c'tors cleaner for speedier development and use (primarily for testing utility stuff where DIP may not have been as important).

As soon as we inverted all the dependencies, pulling StructureMap out was a breeze.

Likewise, for ASP.NET MVC, all the *Context classes can be done away with easily or with minor work.

Locating the controller would be tricky without service location, but I think I'd rather just have an IControllerLocator implementation registered in the cloud rather than the current mechanism of subclassing and overriding methods.

I'd rather ASP.NET MVC say: "You must have implementations of the following 10 interfaces registered in the container cloud in order for dependency injection to work". By default, ASP.NET might use Unity, or even a static container of some sort that has everything hard coded.

MVCContrib could ship with a standard StructrueMap Registry files, Windsor Facilities (or whatever the equivalent is) and whatever the Ninject and Unity equivalents are.

These Registries/Facilities/etc would be pre-configured with all the required ASP.NET MVC dependencies.

If @Haacked/Gu/MSFT were serious about this and interested, I'd be willing to do a spike test on this to prove it but I won't waste my time if it's not in the cards for MSFT to consider.

I know that nServiceBus has an abstract over a container (IBuilder) and then an adapter to Spring and Windsor.

I think that in the Rhino Repository there is something similar.

I'd suggest that, similar to Common.Logging we all just pick one and go with it. I mean, it's one project with one interface in it.

And to Chad, opening up new windows in a smart client does require service locator.

@Chad - I'm afraid I have to disagree.

First of all, at the very least one needs a way to bootstrap their way into the application and some kind of Service Locator is almost surely going to find its way in there at some point. Also, you'll need Service Locator for those times where you need need a clean way to select, at runtime, from multiple available implementations of a service interface. Finally, there will always be times that you want access to something without the overhead of injecting it up front (e.g. cases where instantiated object count is higher but where a particular service or set of services are used through those objects less frequently.)

While I definitely think it is great to minimize the number of points in your application where you work with a Service Locator, there are too many scenarios where it is needed to be able to do away with it entirely.

@Chad again - to be clear, I am in general agreement with the rest of your comment. :)

I think it's great that we standardise a basic interface for an IoC container; however I do have a couple of points.

1. I second the need for the following non-generic equivalents:

object GetInstance(Type t)

object GetInstance(Type t, string name)

object GetAllInstances(Type t)

2. What are the semantics for GetAllInstances<T>()?  Does it return all components registered as 'T' or all components that are a subclass of 'T" or implement 'T' (if T is an interface)?  I think it needs to be well-defined, or it may not make it that easy to plug in different containers.

3. I think it is worth considering exposing a minimum set of Register* methods.  Example:

I'm writing a simple command-line utility that uses the IoC container interface, and based on certain command-line options, allows me to configure which implementation of the INotificationService is used.  I want to programatically register either EmailNotification or ConsoleNotification with the container depending on the option specified.  I also don't want to have a separate / external configuration file with my utility.

4. Attributes...  I know this is a point of contention, and many will argue they do not want to litter their objects with [Dependency], etc; however, to standardize on a few might be worth considering.  They allow the developer to declare their intent in the same code as the class, making it easier to understand the external dependencies from the perspective of a 3rd party.

@Jeremy in a dynamic scenario, I might duck-type the returned object to a type I do know about. I can't statically pass the type I know about because the object I want doesn't implement it.

Or, I might have information about the type I want from somewhere else and want to call methods on it dynamically (for example, if I pass the object to an IronRuby layer and call it from there.

@Haacked - I hear ya. Exposing both flavors is completely sensible.

Pingback from  Dew Drop - August 17, 2008 | Alvin Ashcraft's Morning Dew

"As long as we're going to work in static typed languages, it's a major advantage to achieve extensibility and pluggability by utilizing an existing Inversion of Control container. "

Is it really static-typed languages that demand containers for IOC? Isn't it just languages without first-class/higher-order functions?

Phil:

I understand what you're talking about re: the DLR and GetInstance(string), but I don't know if it has an actual implementation in any of the popular DI frameworks. I know for certain that Ninject wouldn't know the first thing about how to resolve that, since it doesn't use string keys in the first place. :)

I'm willing to add functionality to Ninject to support this abstraction layer, but I think we should just focus on making it the lowest common denominator. Then again, if Ninject is the only framework that doesn't support it, I'll bring it up to par. :)

Rather than agreeing on a common base interface wouldn't be better instead of agreeing on a common fluent IoC API containing enough extensibiliy points so that we can cater for all situations ?

WhenResolvingType<IFoo>().ResolveWith<Foo>().AsSingleton();

WhenResolvingType<IBar>().ResolveWith<Bar>().WhenCallingAssemblyIs(assembly)..

etc etc

I have probably absolutely no idea as to what I am talking about (honest) but I don't think Jeremy's approach to agree on a very basic IoC interface will allow us to go anywhere (no offense!).

Jeremy,

how do you handle the case where your framework requires registration of components for its internal use?

I automatically enroll all the default components of OpenRasta when the framework is loaded, so that whatever IoC is in use they'll receive a registration for those components to resolve them when needed. The behavior is transparent to the user but lets them override this at any time.

I've found that for my needs, covering registration was done through a couple of methods that were indeed the lowest common denominator of all containers, but that is only used for my framework. Users are still encouraged to do their registrations using whatever container-specific API they are used to.

Is that so different from the resolve mechanism for framework writers?

@Jeremy & Sebastien - In my specific case, I expect we'll be imposing convention scanner requirements instead of required registration mechanism support but both options are certainly be appropriate in different situations.

This is why I'm tempted to agree that the absolute lowest common denominator is on the instance retrieval side of things and would not include any particular style or set of registration support requirements. This would still leave the possibility of each framework implementer layering on an additional set of requirements around registration (and/or convention scanner) functionality depending on the needs and style of the framework (and consuming applications) in question.

Jeremy D: My mistake, I misunderstood your post which, for a good reason, doesn't mention registration.

Having had nasty surprises with the multiple overloads of component registration with CastleWindsor I was here hoping for something better.

Next time I will use StructureMap I swear.

It might help your cause that the author of Windsor has joined the MEF team.  hammett.castleproject.org

No petitions! Just to update the world, we're listening and talking about options.

I forget to say, i think this is a great idea! From a naming perspective I like IServiceLocator in that there is nothing particularly DIish about the suggested interface. The main thing is providing a clean pluggable mechanism for accessing services. If that mechanism happens to be a DI container great, but as a user, why do I care.

I don't believe the interface should use generics AT ALL.  As pointed out, there's times you must supply the type at runtime, not compile time.  So you must have versions that take a Type parameter.  So why not have both?  Because it's not a very DRY solution.  Far better to leave the generic versions out of the interface and provide extension methods for this.  I'd also consider using IServiceProvider here.

public interface INamedServiceProvider : IServiceProvider

{

  GetService(Type type, string name);

  GetAllIServices(string name);

}

public static class ServiceProviderExtensions

{

  public static T GetService<T>(this IServiceProvider self)

  {

     return (T)self.GetService(typeof(T));

  }

  // not showing all extensions for brevity

}

Hi Jeremy, I couldn't agree more myself! I'm currently in the process of rewriting LinFu's own IoC container, so this is of a huge interest to me as well.

FWIW, I think the basic service locator interface should support the basic functions:

-Type Registration

-Determining whether or not the locator can instantiate the service type

-A GetService method of some sort that can instantiate the particular service type in question

I think the lowest common denominator approach would be best since no two IoC frameworks are exactly alike, and from the end user standpoint, a common service locator interface would make it easy for people to try different IoC frameworks without having to do a massive rewrite of their code.

It is by no means perfect, of course, but I'll certainly agree to implementing a common interface once all the other IoC container devs agree to do the same thing.

Pingback from  Zen and the art of Castle maintenance  &raquo; Blog Archive   &raquo; Integrating MonoRail with your favorite IoC container

Announcing: The IServiceLocator interface

Today we launched an exciting project on CodePlex, namely the Common Service Locator library . What is

Today we launched an exciting project on CodePlex, namely the Common Service Locator library . What is

Today we launched an exciting project on CodePlex, namely the Common Service Locator library . What is

Today we launched an exciting project on CodePlex, namely the Common Service Locator library . What is

Pingback from  Weekly Links #21 | GrantPalin.com

Common Service Locator