views:

41

answers:

2

Also, how do connection strings fit in?

Presumably, it is ok for the dal to read these values from the config, or should these be passed down from the top?

+3  A: 

I tend to say yes to this.

There are several reasons for encapsulating your custom configuration in a class and then injecting it, including:

  • Testability1 - your config can be mocked out easily. Any classes under test that require config, do not require you to play around with App.Configs just to get the tests working - your are nicely decoupled from Microsoft's ConfigurationManager
  • Testability2 - the configuration itself becomes testable. If you are doing any "playing around" with values (e.g. turning a comma seperated list of values into an array) in your config class, you can test it's behaviour simply and in isolation.
  • Swapability - you can easily swap out your config provider to be config in code, or config from a database because the actual configuration is encapsulated.

So yes :)

Rob Levine
+1  A: 

Joshua Flanagan wrote about this some months ago.

He shows how custom configuration sections can be treated like POCOs, provided via constructor injection.

http://www.lostechies.com/blogs/joshuaflanagan/archive/2009/07/12/how-we-handle-application-configuration.aspx

Grant Palin