How to inject to all child objects automatically

Answer 1

I think what you are proposing is a class that gets a list of properties from a configuration file. If that is true, you should look into the Code Generators. You can create a simple code generator that reads a config file and creates properties in the given child classes. Code Smith should be a good start.

Answer 2

Most dependency injection frameworks allow for injection binding by "convention." For example, you could put an attribute on the property to flag it for injection, and when the DI framework constructs a class it will know to inject a value into that property.

public abstract class Foo
{
    [Inject]
    public Bar Bar {get; set;}
}

public class Baz : Foo
{
    ...
}

public class SomeUtil
{
    Baz _baz;
    public SomeUtil(Baz baz)
    {
        _baz = baz;
    }
}

In the example above, if we can assume that the SomeUtil class is generated by dependency injection, the DI framework can be configured to generate a Baz and populate its Bar property.

I don't know the specific implementation for Spring, but this is the general direction that I'd look in.

Update

When I spoke about binding by "convention," I was referring to auto-wiring. Tobsen's answer has some good references on auto-wiring in Spring. It appears to be more difficult than in Ninject, which is what I have been using. Looking through those docs, however, it appears that you can tell the framework to automatically inject a value into any public property with a specified name or type. In my example above, you could tell it that any property called "Bar" should be injected. Since all sub-classes of Foo contain a property called Bar, they will all have this value injected. This requires a one-time change to your configuration file, and everything after that should "just work."

I'm getting the impression, however, that the real root of your problem is that you aren't using dependency injection quite the right way. Tobsen picked up on this, too. If you ever say new Baz(), this is an anti-pattern of dependency injection. Instead, your dependencies should trickle up into the highest point possible in your code (what DI books call the "context root", where you will actually have code asking for the dependency you need. Something like this:

public static void Main()
{
    var someUtil = (SomeUtil)ContextRegistry.GetContext()["SomeUtil"];
    someUtil.DoSomething();
}

In the process of figuring out how to construct a SomeUtil, Spring will figure out that it first needs a Baz. It will notice that the Baz has a Bar property on it, and so it will create a Bar and inject it into that property, then pass the Baz into the constructor for SomeUtil, and then return the SomeUtil that it just created.

If this isn't perfectly clear to you, I'd strongly encourage you to read a good book about Dependency Injection. It takes a little time and practice to learn to recognize the patterns and anti-patterns of dependency injection, but it is very rewarding once you do.

Answer 3

You can use autowiring (see 5.3.6. Autowiring collaborators in the spring.net documentation) for automatically setting that Injectable-Property via spring without the class knowing anything about spring.

You wrote "I want to avoid to make the abstract class like this" and that is a wise choice since you should not talk to your inversion of control container.

I wonder though who is responsible to create instances of those classes derived from Foo? I think you should let spring create objects of those Asp.Net page classes derived from Foo. It seems Spring has extensive support for Asp.net pages (Spring.Web.Support.PageHandlerFactory, Spring.Web.Services.WebServiceHandlerFactory etc in Spring.Web) - I would have posted an example configuration suitable for your needs but I haven't used ASP.Net yet. So instead here are some links:

• Integrating Spring.NET with ASP.NET Web Site
• Chapter 22. Spring.NET Web Framework

You should also have a look at the spring web examples which are part of the source code distribution.

==BeginEdit==

In order to answer this, I need to know what the decision logic is for instantiation of the children. i.e. when/where is a concrete child object requested by whom? Who decides on the concrete type of the object to create? If you had control over the instantiation of the concrete child class you could create the instance of the concrete type and tell spring to set the properties afterwards:

void ConfigureObject(object target): Injects dependencies into the supplied target instance. The name of the abstract object definition is the System.Type.FullName of the target instance. This method is typically used when objects are instantiated outside the control of a developer, for example when ASP.NET instantiates web controls and when a WinForms application creates UserControls.

void ConfigureObject(object target, string name): Offers the same functionality as the previously listed Configure method but uses a named object definition instead of using the type's full name.

This would keep your objects POCOs and you have only one point of object creation with a dependency to spring.

If the logic what type to instantiate can be resolved via an regex for the page request, Spring has a solution for that too: 22.4.3. Injecting dependencies into HTTP handlers and handler factories. However you have to tell spring which objectdefinition to instantiate and there seems to be an automatism which might be useful in your case (depending on what the logic for instantiation of your child classes is)(also 22.4.3 of the 1.3 spring documentation):

Spring's DefaultHandlerFactory uses the .NET class System.Web.UI.SimpleHandlerFactory to create handler instances and configures each instance by using an object definition whose name matches the request URL's filename. The abstract object definition of DemoHandler.ashx is an example of this approach. You can also configure standard classes that implement the IHttpHandler interface as demonstrated in the example above for the class MyCustomHttpHandler.

==EndEdit==

==Begin2ndEdit==

It seems that Erich Eichinger (one of the spring.net developers) once had exactly the same problem as you do. It seems that in the end he had to talk to the container exactly like you did. As Erich writes in the forum thread, he wasn't too happy to have a direct dependency to the IoC Container. Maybe his proposed solution has been integrated into Spring. I'll try to find out.

==End2ndInit==

Answer 4

Hi,

sorry I have only limited time atm, plz ping me if the description below should be too short/abstract

First, there is no such functionality yet available. But with a few lines of code you can do this on your own.

In general below I will be pursuing the idea of mapping a particular class onto an object-definition to be used for configuring the instance. Something along the lines of

if (object is MyBaseClass)
     applicationContext.Configure(object, "myObjectDefinitionName");

Here's the outline of a solution: Since your problem is ASP.NET WebForms-related, an HttpModule is a good starting point to hook into creating and configuring .aspx pages. The idea is to write your own IHttpModule that performs the page configuration right before it gets executed. Basically all you need is

public class MyBaseClassConfigurationModule : IHttpModule {

  private System.Collections.Generic.Dictionary<Type, String> typeObjectDefinitionMap;

  public void Dispose() {}

  public void Init(HttpApplication context) {
     context.PreRequestHandlerExecute += context_PreRequestHandlerExecute;
  }

  void context_PreRequestHandlerExecute(object sender, EventArgs e) {
    IHttpHandler handler = ((HttpApplication )sender).Context.Handler;
    foreach(Type t in typeObjectDefinitionMap.Keys) {
        if (t.IsAssignableFrom(app.Context.Handler.GetType)) {
            Spring.Context.Support.WebApplicationContext.Current
              .ConfigureObject(handler, typeObjectDefinitionMap[t]);
        }
    }
  }
}

and configure your module according to 22.4.2. Injecting dependencies into custom HTTP modules.

hth, Erich

Answer 5

If I understood the question correctly, the solution is very simple.

Declare the BasePage object exactly like you did, and add to it abstract="true" property:

<object id="BasePage" type="BasePage" abstract="true">
  <property name="FooProp">
    <object type="ConcreteInjectable"><property.... /></object>
  </property>
</object>

All the derived instances should be configured like so:

<object type="somePage" parent="BasePage"/>

If you don't want to configure each instance separately, you should consider using MEF, which make this task much easier to preform.