views:

45

answers:

1

Hi, I am building a application which will use DI Framework to load components to fetch data, from various sources like external web service or DB. Now components will need some of application configuration like web service url or database connection string. Keeping all that stuff in Web.Config and passing it via constructor parameters is basic option i have.

<constructor>
  <param name="connectionString" parameterType="string">
    <value value="AdventureWorks"/>
  </param>
  <param name="dataService" parameterType="IMyService">
    <dependency />
  </param>
</constructor>

But this option is not scalable and config file can become bulky as number of components will grow. Can anyone please suggest better practice? Regards, Tom

+1  A: 

It's either XML or code (but they're not mutually exclusive). That's what most (all?) IoC containers do. As an example see Windsor's XML config docs and code config (fluent registration) docs. Another code config option is creating a DSL, like Binsor.

Usually I mix both approaches, registering as much as possible in code, except the parts that need to be configurable, which go as XML config. Or you can even do the registration in code and read simple parameters from the appSettings.

Of course you could also put your configuration in an INI-style config or even a database, but that usually doesn't make much sense.

Mauricio Scheffer
+1 I think I know what you mean (and if so I agree), but your wording makes it sound like XML and code are exclusive options. The whole point is that you can mix XML with code (and you seem to be implying this in the rest of your answer) so that only the truly externally configurable options are left in XML.
Mark Seemann
Thanks Mark, I'll edit to make it more clear.
Mauricio Scheffer