ASP.NET and storing dynamic data - XML or Database?

Question

I have an ASP.NET application and need to store some settings.

The settings are, among other things, titles on pages shown in my application. The titles are changed on a regular basis (every week or so) and I'm wondering on how to do this the smart way:

1. Save the settings in the web.config (slow read time, and application has to be restarted to detect changes).

2. Save the settings in a database.

3. My own XML file (such as a custom configuration section in its own XML file).

I'm looking for anything that could point me in a better direction.

What would you do?

Answer 1

There are two issues here:

1. Storing settings.

2. Storing dynamic values that are shown on each page.

If you're going to store application settings, then I'd use a Custom Configuration Section. It allows you to create meaningful names for your settings, instead of the key/value pair approach the web.config uses. You can stick this Custom Configuration Section in its own XML file and reference it in your web.config.

If you're going to store dynamic data (not application settings), then I'd use a database if you already have one.

The reason is that the web.config is meant to hold settings. You can use it to hold key/value page pairs, but that is messy. Truly dynamic data should be held in a database store along with any other database data. You mentioned that, so using a database makes the most sense if that's the type of data you are going to store. Page Titles are not application settings, they are dynamic data. If it's localized data, then that's a different story, but you haven't given any indication that it is.

Answer 2

Why not use umbraco as a content management system for all your site content / settings?

Umbraco sits in the background of an asp .net site until you decide to integrate specific elements.

You could even schedule in the changes to pages ithout code / setting changes as they sound more like content elements.

Answer 3

The web.config is a place where you store information relevant to the application, i.e. configuration that the application cannot live without. Hence, database server name is Okay, but page name of the default.aspx is not ok.

The other two options are equal in my opinion, only if the titles are changed by an administrator, then it's easier to update an XML file in notepad, not database table in SQL server (unless you have a nice GUI for updating it).

Edit: you should not be afraid of web.config having slow read times - the file is reloaded only when you "touch" it, that is, when the "modified" attribute of the file changes.

Answer 4

Based purely on the fact that they are changed every week or so, I'd store them in the database, and create a page to administer the values.

There are a lot of factors here though. One thing to consider, is that changing configuration settings does cause the application to restarted, because ASP.NET only reads the configuration settings on start-up, and then caches them for the duration. Constantly changing the config files could cause issues with orphaned sessions and whatnot. This isn't very likely, but possible.

Using an xml file on the server, that is not part of .NET's configuration settings, would get around this, but editing it is more prone to error and has a cost of reading it for every request.

Creating a page to administer the values is more initial work, but I think it would pay off in the long run.

Answer 5

I would use a database.

As others have said, web.config is really meant for application-level settings only.

One issue with an XML file is that if you ever decide to move to a load-balanced scenario, then you have to worry about how to replicate that file from one server to another. It's considered a best practice from a scalability and security perspective to not have any application dynamic data in the filesystem at the web tier (if you want to be able to update the file, it means you would have to allow your web app to have write access to the local filesystem, which is a security risk).

Putting it in the DB allows you to read it once when your app first starts. You can then cache all or part of it in memory with a SqlDependency or SqlCacheDependency, so that the code receives a notification if the DB table changes (you can do something similar with an XML file, if you must).

With the info in the DB, you can more easily add a load balanced server later, if you need to, and your web app can stay read-only.