This project is read-only.

Easy registration


Here's the code for "easy" component registration (feel free to rename), which is the equivalent of registering a component so that all constructor dependencies are resolved from the container via lambdas.

It is implemented as a void extension method, but for general usage it would probably make sense to return IRegistration<T>


dcazzulino wrote Jul 7, 2009 at 4:29 PM

This could also be just an overload to Register that doesn't receive parameters...

mabster wrote Jul 10, 2009 at 1:59 AM

Yeah, I think a parameterless Register() overload would be a nice way to do this.

mythz wrote Oct 27, 2009 at 10:34 PM

Actually this is close to what I was looking for, you should also consider a Register overload that doesn't take typed parameters, i.e. container.Register(typeof(Interface), typeof(Impl)) so we can auto register a type at runtime (on AppDomain startup).

mabster wrote Nov 23, 2009 at 12:39 AM

Oh man, I just gave this a go in a test project and it cleaned up the registration code a lot. Particularly if you add this method:
    public static void Register(this Container container)
... so that you don't need to specify both the interface and implementation of the service type (if they're the same).

mythz wrote Feb 10, 2010 at 6:43 PM

I've posted about this in the discussions but it may get lost so I'll re-post:

I've developed a generics/expression based AutoWire wrapper for my web service framework that lets you register 'runtime types' around Funq's generic interfaces here:

It's built with the same spirit as Funq where all the perf cost happens during the 'registration phase'. Basically when you register a 'runtime type' it goes through and 'binds' the Funq resolver to the largest constructor and all its public properties that have registered dependencies.

It exposes the following API's allowing you to register 'runtime types':

public void RegisterTypes(params Type[] serviceTypes)
void RegisterTypes(IEnumerable serviceTypes)

At the moment it's just a wrapper class around the Funq container so I could add this functionality without modifying the existing Funq code-base.
Although if this is a useful (and right) approach I could rewrite it as an extension method or merge it into the existing code base, etc, whatever is the preferred method.
Of course it will only work in environments that support expressions.
I do have developed an equivalent Reflection-based solution for this purpose, although it is probably not best to include these slower API's as the whole point of Funq is to run fast on embedded devices :)