9

I don't agree that storing settings in a database table is a bad separation of concerns. Your "concerns" will be separated by not defining a relationship between the settings table and other tables in your database. This is fine. The main thing to consider is how you expect the administrator of your system to make changes to the settings. It's much easier ...


7

A good starting point is Jeff Atwood's article: Was The Windows Registry a Good Idea? It gives a lot of good reasons not to use the registry. Among them: The registry is a single point of failure. That's why every single registry editing tip you'll ever find starts with a big fat screaming disclaimer about how you can break your computer with regedit. ...


4

The largish legacy application I maintain has gone back and forth on this over the years, but has evolved towards keeping most settings in the DB. Yes, the DB connection string is read from the config file. This is a desktop application that heavily uses a DB and which has quite a few settings. If you have very few this will be less applicable, but these are ...


3

Have you tried SQLite? It's a self contained embedded lightweight SQL database. A lot of applications use it to store user settings and other persistence use cases in Desktop Apps - all the major Browsers, OSes, Skype and more. Of course this would mean your user settings won't be "Human Readable" as such. Not as much as XML anyway. Is that a requirement ...


3

It's the lack of style guides. On Mac systems you have Preferences fixed to store your options and settings. Other systems prefer whatever the programmer's taste is to name preferences.


3

I have currently my config files in the build process, however whenever i will have the opportunity i will externalize them. Here is a general answer : Because the client may need to change some parameters without having a new delivery. Let's say we use a database, and for a specific reason, the client wants to change the database to point to a new ...


3

I would suggest that the Windows Registry is best left to Windows itself to play with. Parts of it are inaccessible to regular users. Parts of it are inaccessible to certain types of application (32-bit processes running on 64-bit versions of Windows). It's a completely proprietary storage mechanism, which can change, without warning, with any upgrade ...


2

What do you think of this solution? Do you have any alternative ideas? Or some criticism? It's fine. Personally, I would just have a public static readonly instance on ServerSettings rather than the nested type. Then you can pass around ServerSettings.Default (or use it if someone passes in null somewhere). Plus it seems to be a little cleaner to me. In C#,...


2

If you're using NSDefaults (or CFPreferences), you can update the default settings immediately. They get pushed to the background process cfprefsd (short for Core Foundation PREFerenceS Daemon) which holds them in RAM and writes to disk at its leisure. Killing your app does not kill cfprefsd, so the settings don't get lost. (Killing cfprefsd, which I've ...


2

You wrote Some applications have use for values to be remembered between sessions well, that is true whenever you have to persist data would be to create a file of a specific format (XML, JSON, ini, or something else) in the user's data directory and use it for such values. [...] One example is the timestamp of the last time a certain function was ...


2

What you're probably looking for is a PropertyGrid. Winforms has one native. You can find one for WPF here. There are several available for HTML5.


2

I think it depends on the nature of the settings. Some settings are basically numbers, like number of results to display or a zoom factor or such like. These settings can be read from your settings structure (or API) as needed and plugged in as parameters to functions in your code. I think these are straightforward. Other settings control functionality, ...


2

There is nothing wrong in having tables with no relationships. The choice of a database in order to store those settings is perfectly fine and quite common. The only issue you might encounter is performance, but basic caching at server level would quickly solve this. A usual problem is what types of columns should you use for such table if you're relying ...


2

Yes it is correct don't overthink it. UML is just a tool if it works that way for you and people with who you work to achieve your goal it is ok. Spending time on making 'correct' UML is probably not best use of your time. Spending time to communicate effectively is best use of your time.


1

Consider to implement a more declarative approach for validate_settings. You wrote Still, I can't think of a better way other than checking each individual key in each individual dictionay/subdictionary, since each key has a different name, each subdict has a different structure and many different data types are used for values. I can think of one. I ...


1

You don't have to test every value, as you're not testing the actual config. You're just testing the one "unit" which is the validate_settings method. Running this test won't tell you if your settings file is good, but it does tell you that you won't be able to start the program if your settings file is not good. You haven't shared the code for ...


1

With help from RubberDuck's comments, I am able to use the Application Settings function built in to the .NET framework. This is handling all the on-the-fly changes, as well as persistent changes throughout the program. On each control that I want to change the settings with, I start by assigning the setting for the control. Then, I run the logic (i.e. If ...


1

Where you choose to store configuration should be based on the purpose and the editor. If the user chooses the settings and there is an installed client program, opt for a per-client INI file or registry settings. For universal settings you can opt for server based files or database. Configuration stored in a database tends to be simpler i.e. just key ...


1

Would it make sense to create an interface for each handler to provide access only the settings that are of handler's concern I would generally say yes. If each object takes a generic config then that makes life very easy for you (the programmer), but the user/client is only going to discover missing configuration during runtime. I would rather have the ...


1

Properties.Settings are stored for the user on the machine. If you want the settings to be common to all users and/or all machines, this method would not do. You also may want to have input parameters for the application that steer its behavior rather than preferences, and have several sets of them ready to be used in different senarios. For this, Properties....


1

Do not generate code, generate values instead. Why you need encapsulation I would suggest that you avoid code generation from one language to another for two reasons: It makes the code difficult to read; small snippets of JavaScript in among lines of PHP cannot be picked up by IDEs and is difficult to follow even for programmers well versed in both ...


1

Given that your application needs that kind of complexity, then here are my 5 cents (I will use Java code): Settings are split in two categories acording to whether or not they take immediate effect when they are altered. dynamic: have an immediate effect in the application's behavior static: don't have an immediate effect in the application's behavior and ...


1

In the distant past, I would have suggested using the registry (as opposed to an INI file). These days, I would lean toward file-based storage of settings and configuration. The user-changeable parts of the settings should be persisted using the Isolated Storage API.


1

I strongly advise against using Properties.Settings.Default.aSetting all over the place. If you do You bind yourself hand and foot to whatever storage mechanism you hook up (by default the app.config and user.config files). You turn every function that uses Properties.Settings.Default into something that can only be tested through slow integration tests ...


1

The big value of application settings in .NET (called "Windows Forms Application Settings") is that they provide automatic persistence of settings, that can be configured per user. Because of that, I only use them in the case of a rich client application, where I need the user to configure some settings that should persist when the user launches the ...


1

Other. How about a static variable? Singletons don't play well in the web environment, but that may work to your advantage. See also Asp.net session variable. Another thought - you're right about a one column / one record table, but if you already have the infrastructure set up to read & write tables, then the additional "cost" for this one would be ...


Only top voted, non community-wiki answers of a minimum length are eligible