I'm designing a small application infrastructure library, aiming to simplify development of ASP.NET MVC based applications. Main goal is to enforce convention over configuration.

Hovewer, I still want to make some parts "configurable" by developpers.

I'm leaning towards the following design:

public interface IConfiguration
{
    SomeType SomeValue;
}

// this one won't get registered in container
protected class DefaultConfiguration : IConfiguration
{
    public SomeType SomeValue { get { return SomeType.Default; } }
}

// declared inside 3rd party library, will get registered in container
protected class CustomConfiguration : IConfiguration
{
    public SomeType SomeValue  { get { return SomeType.Custom; } }
}

And the "service" class :

public class Service
{
    private IConfiguration conf = new DefaultConfiguration();

    // optional dependency, if found, will be set to CustomConfiguration by DI container
    public IConfiguration Conf { get { return conf; } set { conf = value; } }

    public void Configure()
    {
        DoSomethingWith( Conf );
    }
}

There, the "configuration" part is clearly a dependency of the service class, but it this an "overuse" of DI ?