During the development of PoCoRail there have been a couple of places where third party frameworks could carry out a portion of the work. Specifically Logging and Dependency Injection.

For logging, I chose to use Log4net as opposed to writing my own system or using the built in dotnet diagnostics. Although this is an extra dependency, it doesn't require users of PoCoRail to understand it unless they want to view the logging information created within the framework. Also, I wasn't at all motivated to write Yet Another Logging Framework and felt that I would use a good portion of the functionality provided by log4net.

However, I've been reluctant to use a Dependency Injection framework. Dependency Injection would have to be exposed to the users of PoCoRail in order for them to register the concrete types they wish to use for things like Presenters. The problems with this are that people may wish to use a different DI framework in the rest of their project, or alternatively may not use a Dependency Injection framework at all. While Inversion of Control isn't too complex a concept to grasp, a framework which supports all the various details of container managed injection can be quite overwhelming to the uninitiated.

One of the key aspects of a DI container is Concrete Type Instantiation (CTI anyone ? :). Injecting instances and properties into the concrete type's constructor obviously needs to be supported where there is no default constructor. The current version of PoCoRail has its own implementation of these tasks which are very specific and thus somewhat simpler than a generic system.

Registration of concrete presenters is taken care of by a call to:

PresentationManager.AddPresenters(Assembly.GetExecutingAssembly());

The default factory for creating a Presenter is then implemented as:

public class PoCoRailPresenterFactory : IPoCoRailPresenterFactory
{
    public TPresenterInterface CreatePresenter<TPresenterInterface>(IPoCoRailWebContext poCoRailWebContext)
    {
        return PresentationManager.CreatePresenter<TPresenterInterface>(poCoRailWebContext);
    }
}

Due to the comparative simplicity of this, and the lack of any external dependency, I think I've gone the right way with this decision, but the recent release of StructureMap 2.0 with its programmatic configuration has made me consider the issue again. As there is a PresenterFactory in place, I'm considering writing an alternative derivation to support the use of StructureMap. This should allow people to choose what they feel most comfortable with. There is also the possibility that I could utilize StructureMap in creation of any UserControl Views.