Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 ?

share|improve this question
    
You may want to narrow it down to the individual items being configured instad of having a configuration class. –  user1249 Sep 25 '11 at 16:44
add comment

1 Answer 1

Normally DI frameworks do something like container.GetInstance<T>() to get an instance of the type T. This doesn't require each new type to have a code change to your configuration class. Then you can set it up like container.Configure(x => x.For<T>().Use(() => default(T))) or whatever else makes sense.

Now where the power really starts to shine is when you have...

public class Service
{
  public Service(IConfigurationObject config)
  {
    _config = config;
  }
  readonly IConfigurationObject _config;
}

And the container automatically fills out your constructor with the dependency. I'd start out with understanding a container before digging into this too deeply yourself. http://structuremap.net/structuremap/QuickStart.htm is as good place to start as any other.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.