I have what I think is a small improvement to the code for easy registration (from here:
Currently the code will look up the constructor on the implementation type with the most parameters and call Resolve() on each of those parameters. However, I found a use case where your implementing type has already been registered with the container. In
that scenario, you want Funq to use your existing registration function rather than taking a guess at the constructor to use.
So I have changed the method to look like this:
public static void Register<TService, TImplementation>(this Container container) where TImplementation : TService
Func<Container, TService> exp;
exp = c => c.Resolve<TImplementation>();
var lambdaParam = Expression.Parameter(typeof(Container), "ref_to_the_container_passed_into_the_lambda");
var constructorExpression =
exp = CompileInterfaceConstructor<TService>(lambdaParam, constructorExpression);
Essentially this uses my "IsRegistered" method (submitted in a patch) to first check if the implementation is already registered, and if so just call resolve directly on it.
The reason I've found this handy is because I have also added a "named registration" overload to the easy-registration class, and I'm able to do this:
// proper registration code for Foo and Bar
cont.Register<FooImpl>(c => ...);
cont.Register<BarImpl>(c => ...);
// named registration for both
So I have given Funq enough knowledge to properly construct a FooImpl and BarImpl, but I'm relying on "easy registration" to register both of them as an IService by name. Now my "host" class can ask for an IService by name and get the
correct implementation. If we didn't check that FooImpl and BarImpl were already registered, Funq would bypass my special registration function and try to create them by resolving their constructor parameters separately.
Does that all make sense?