Scott has a good essay on Dependency Injection. I have become a huge fan of dependency injection during my stay here at CodeBetter and appreciate its value not only from a testing point-of-view but also for helping reveal the intent and dependencies of a class. I use it all the time and have experienced Windsor, StructureMap, and ObjectBuilder.

In the real-world, however, it can be a bitch because inevitably you don't have as much control as you would like.

Take the example of Webforms and using the Model-View-Presenter Pattern. By the very nature of Webforms, the view gets created for you but has a dependency on a Presenter Class. 99.9% of the examples I have seen on the Internet about getting access to the Presenter Class from within the View are something as follows where you are doing all the manual wiring:

public partial class AddCustomer : Page, IAddCustomer
{
    private AddCustomerPresenter _presenter;
    
    protected Page_PreInit(object sender, EventArgs e)
    {
            // Constructor Injection of Data Access Service and View
            ICustomerDAO dao = Container.Resolve<ICustomerDAO>():
            _presenter = new AddCustomerPresenter(dao, this);
            
            // Property Injection of Logging
            ILoggingService logger = Container.Resolve<ILoggingService>():
            _presenter.Logger = logger;
    }
    
    //...
}

Or, the presenter has a default constructor and wires up its needs itself, which is more about Service Location than Dependency Injection.

Either way, this still stinks in my humble opinion as I don't want to have to manually inject the Presenter Class dependency into the view.

I would rather have something like I get from the Web Client Software Factory where the initial Presenter Class is injected for me by the Composite Web Application Block and ObjectBuilder by simply decorating a property with a [CreateNew] Attribute:

public partial class AddCustomer : Page, IAddCustomer
{
    private AddCustomerPresenter _presenter;

    [CreateNew]
    public AddCustomerPresenter Presenter
    {
        set
        {
            this._presenter = value;
            this._presenter.View = this;
        }
    }
    
    // ...
}

That's it. No manual wiring of dependencies. No service location. Everything is done by the Composite Web Application Block and ObjectBuilder. 

You can actually see this in my Web Client Software Factory and Enterprise Library 3.1 Sample Download as well as hear about how it happens in my Composite Web Application Block and ObjectBuilder Dependency Injection Screencast.

My point is not to discuss WCSF here, but to find out how others are doing this initial wiring. Are you just manually wiring the Presenter into the View or do you have a "framework" that does the initial wiring for you like the case with the Composite Web Application Block?

I also don't know for sure, but I don't believe StructureMap and Windsor have a good way out-of-the-box to inject the dependencies into the view after it has already been created as is the case for webforms. I did talk about it here some time ago as a mental exercise:

Wire-Up View-Presenter Pattern Like Web Client Software Factory - Castle Windsor for Dependency Injection

It would also be nice to have a solution that will work in a Partial Trust Environment so you can use it on small shared hosting applications as well.

This tends to be the real-world warts that you don't often hear about with Dependency Injection and I am disappointed I haven't been able to find a good answer. Anyone have any good ideas?