views:

243

answers:

4

There are multiple values I have been storing in ASP.NET configSections sections for each "module". I have been wondering if they even belong in these files at all.

The background stands at: These are multiple instances of the web application deployed. All use the same database but have their own settings.

I'm sure that differences between development and production go in the config files. Some of the values I know should include: connection strings, providers to use, setting debug, etc.

I have factored out all the common pieces in to classes with their own rules and methods. The pieces left are miscellaneous settings for each module in each site. Some of the options I'm unsure of include:

  • For ModuleA, Show/Hide Option
  • For ModuleB, What is the terminology to be used for this field
  • For ModuleC, Allow end user to perform X action
+3  A: 

Mmm these sounds like things that you might want be able to change at runtime for your application without having to modify the app.config. One rule of thumb I like to follow is that anything in the config should be for the deployment or server configuration. In this case your settings appear to be modifying the application behaviour and so I would probably move them into the DB if it is not alot of effort.

smaclell
Do you have any recommendations for the database layout? Should it go in to the database, we are pondering having either a single table with applicationId, moduleId, key, and value as fields or explicit defined tables (IE: config_moduleA, config_moduleB, etc)?
single table with a column for module id. You can then add subsets of modules, or additional modules, easily. Its also much more manageable for backups and DB migration, and practically everything.
gbjbaanb
It really depends on the setting and how configurable you want to make it. I would start off at a single table like @gbjbaanb says then go from there. Good luck.
smaclell
+1  A: 

ModuleA and ModuleC sound like they may be user profile information. If they're not dynamic by user, but you could add later functionality, then maybe move them to a DB.

I've written apps where ModuleB would have been put in a DB also. Things like form labels, etc. can easily go in a DB. If, at a later date, someone decides to add or remove colons to all form labels, that's a pretty easy thing to do if all of the text is stored in a DB.

Jarrett Meyer
+1  A: 

Consider the situation when you need to edit one of the values.

If the value is in web.config, saving the change to that file will cause the app to recycle, inconveniently throwing out current users. Not so much of a problem if your app is on an intranet only used during business hours (though you could get an angry call from the guy who stayed to work late). But potentially a problem on a public website with international users.

If the value is in a database, it will have no impact on the app's processing in that way.

Either way, consider whether the values are cached in the app's RAM (web.config is). Are the database values in an Application variable, or in Cache? If so, you may not know when the change will occur. Unless you want to restart the app.

And, what different access and permissions would the appropriate admins need to make the changes? Someone would have to have access to the web server(s) to change web.config, or to the database (and table) to change that.

DOK
A: 

A few questions: Why do you use the same DB for multiple instances of the application, and how will that effect maintanence? In the future will it be an option to split the db in order to improve performance? Does the config model support that change better then the DB based one?

In other words, you will have to consider a lot variables in order to answer your question :-)

Kasper
Multiple instances are centrally hosted on the same application and database servers but require completely different sets of settings.