API For Configuring Injection - Specify Actual Properties and Methods?

Mar 13, 2008 at 4:19 PM
Edited Mar 13, 2008 at 4:21 PM
This may be a very naieve question, but I wonder if there is anyway to get away from strings when specifying properties and methods and get a bit more compile-time checking by specifying actual properties and methods on the objects themselves?

Chris' example:

container.Configure<InjectedMembers>()
   .ConfigureInjectionFor<Foo>(
      new InjectionConstructor(12, "Hello"),
      new InjectionProperty("MyProperty"),
      new InjectionProperty("MyStringProperty", "nifty"),
      new InjectionMethod("InitializeMe", 42.0, new ResolvedParameter(typeof(ILogger), "SpecialLogger"));

might look like:

container.Configure<InjectedMembers>()
   .ConfigureInjectionFor<Foo>(
      new InjectionConstructor(12, "Hello"),
      new InjectionProperty(Foo.MyProperty),
      new InjectionProperty(Foo.MyStringProperty, "nifty"),
      new InjectionMethod(Foo.InitializeMe, 42.0, new ResolvedParameter(typeof(ILogger), "SpecialLogger"));

It may not be possible or even be a good idea for other reasons, but I rather enjoy how other tools, like RhinoMocks, uses the strongly-typed notation as opposed to strings. Maybe we don't even have to mention Foo over-and-over again in my example as well, since we know what we are configuring.

Regards,

Dave
Mar 13, 2008 at 6:22 PM
You could clearly define new InjectionMember-derived classes that would leverage lambda expressions for strong type checking:

container.Configure<InjectedMembers>()
   .ConfigureInjectionFor<Foo>(
      new InjectionConstructor(12, "Hello"),
      new InjectionProperty<Foo>(x = > x.MyProperty));

Then it's a matter of reading through the lambda expression, extracting the property name and passing it down to the approprite strategy.
Mar 13, 2008 at 8:26 PM
The problem is that Foo.SomeProperty doesn't evaluate to a reference to the property, it returns the value of it. And a property is a method call anyway.

The lambda syntax Francois mentions above is the best alternative, but it requires .NET 3.5. Since we're explicitly targetting .NET 2.0, we're out of luck.

RhinoMocks works because it leverage's Castle DynamicProxy to generate subclasses on the fly. I don't see how that would help much in this case.

However, since this is an extension, there's nothing stopping folks from experimenting. I'd love to hear ideas on how to make it compile time type safe.