Injecting appSettings

[Andrew Davey]

Something cool I created today with Ninject...

I created a provider that allows me to do this:
class Foo {
public Foo(AppSetting bar) { // AppSetting is a simple wrapper
around a string
Console.Write(bar.Value)
}
}

where web.config contains:
<appSettings> <add key="bar" value="123" /> </appSettings>

The single line to bind the provider:
Bind<AppSetting>().ToProvider<AppSettingProvider>();

An finally the provider:
class AppSettingProvider : Ninject.Core.Creation.IProvider
{
public object Create(Ninject.Core.Activation.IContext context)
{
return new
AppSetting(WebConfigurationManager.AppSettings[context.Member.Name]);
}

public Type GetImplementationType(Ninject.Core.Activation.IContext
context)
{
return typeof(AppSetting);
}

public bool IsCompatibleWith(Ninject.Core.Activation.IContext
context)
{
return
WebConfigurationManager.AppSettings[context.Member.Name] != null;
}

public Type Prototype
{
get { return typeof(AppSetting); }
}
}

This was so simple and easy to figure out - beautiful!
I'm more impressed with Ninject each time I use it.
:)

[Nate Kohari]

Andrew:

Nice! That's pretty cool stuff. One thing you might want to change is to use context.Target.Name rather than context.Member.Name. The member is the member (constructor, property, method, or field) that's being injected, whereas the target is the actual point that is receiving the value. In the case of properties and fields, the member and the target are identical, but for constructors and methods, the target is the *argument* that is receiving the value. If you use context.Member.Name, you will end up with the name of the constructor or method rather than the argument.

I'm working on an extension to support configuration injection, and I'll keep this in mind to see if I can support something like it. Thanks again!


-Nate

[Matt Hinze]

Cool. Yeah, I'm now getting into providers too.. very fun.

This is the one I whipped up to allow injecting the current IIdentity into a service class in an ASP.NET app:

public class WebIdentityProvider : SimpleProvider<IIdentity>
{
    protected override IIdentity CreateInstance(IContext context)
    {
        return HttpContext.Current.User.Identity;
    }

    public override bool IsCompatibleWith(IContext context)
    {
        return HttpContext.Current != null;
    }
}

Using IoC with HttpContext wasn't something I was able to figure out before...

[Nate Kohari]

Matt:

Yeah, providers are great, they can act like a factory or you can use them to create your own customizable resolution mechanism. Nice use of IsCompatibleWith(), too -- as I remember, I added it to support generics, and I hadn't considered using it in that way. You just taught me something about my own code. ;)


Thanks,
Nate

[Andrew Davey]

Thanks for the heads up - I was using property injection in my
application so hadn't hit that issue. I've changed it now though to be
safe.
Providers (and Ninject in general) seem to offer lots of power. I'm
interested to see what other clever uses people invent.

> >  :)- Hide quoted text -
>
> - Show quoted text -

[Duncan Godwin]

An alternative for injecting the HttpContext is using the
ToFactoryMethod(() => HttpContext.Current.User.Identity);

[Andrew Davey]

Agreed, ToFactoryMethod is a very handy shortcut.

Something else that might be cool for ASP.NET is injecting request
cookies into a Controller class, using a provider.
This makes for much easier testing as well since there is no need to
create a mock context, request and cookie collection.