Where to store user's interface choices?

What is the widely-accepted way to store interface choices, such as 'Do not show this message again' settings, and any other interface-specific choices of the user? Registry? Settings files? I can also store them in a database, since my program already has access to one.

EDITS My current program is local, however in the future I would like to make开发者_如何学C it web-based.

A non-web-based program:

I wouldn't use a database. What happens if you decide to switch the database? Now you have to migrate the user data. What happens if they uninstall?

In Windows, settings files in the user's AppData folder are appropriate. It's also acceptable to not delete these on uninstall, so the settings will persist across that. I would shy away from the registry for user settings. That area is more appropriate for system settings.

There's a similar area in *nix systems, but I'm not sure off the top of my head. It's been too long.

A web-based program with local settings:

Cookies are pretty much the only computer-specific option for a web-based program. IP-based filters are a bad idea, since most consumer internet options will rotate IPs once a day to once a week. You could MAC filter, but that would involve using raw sockets to get the MAC address. And even then, you will probably end up with the address of a router, not a computer. Meaning two people on a single router would get the same settings.

A web-based program with global settings:

Your program should query a web service for this. The service is then free to implement it in whichever way is best at the time. A database is fitting in this scenario, as it's likely that your user data already exists and is keyed therein, providing an easy way to associate data with particular users.

if its a Web-related Environment: depends on how long you want them to stay. If there is a member registration within a database it would totally make sense to save it in the database. Else you could just save it as a cookie or ip/setting in a database.

Assuming you mean on a Windows application, the .NET Application Settings feature uses the filesystem by default (though you can use the registry or anything else, as it's pluggable).

You can store them where ever it's most convenient.

In the database - if the database is remote you don't need access to the local file store, but it does mean that if the connection's not there you can't access the preferences.

In the registry - you need to make sure that you are using the CURRENT_USER area so that the user can actually write to it. Windows specific.

In a file - storing locally means that you're not relying on the connection to the database, but again you need to make sure that the user has rights to the folder you want to save the file to. C#/.NET provide classes for reading and writing user settings files so this is probably your best choice.

It is typically handled by Windows via API. MSDN article on How to: Program Exception Message Box explains how to do it with .NET. According to the article, the exception is stored in the registry if you want to store the decision permanently in that manner.

You can also store the decision in a custom XML config file, use your Application Settings file to store it, or in a database. It is up to you on the simplest implementation and least headaches.

The new recommended way is to store it under the User's Application Data directory. See Data and Settings Management at Technet.

On Windows, the "new" way is to store the configurations in the user's "App-Data" (CSIDL_APPDATA) folder.

My recommendation would be a file (INI, Settings, etc.) stored in the application installation, or in App_Data. Storing it in the Registry is definitely a popular way to do it, but cleaning it up when it's no longer relevant doesn't seem to be so popular. So if you decide to use the registry, make an effort to clean up after yourself if needed (uninstall, registry entry structure change, etc.)

I have stored individual user settings in the database for a WinfForms application that used a location specific database. This worked nice because as users logged in on different client machines, their display settings moved along with them.