Hi all
I've posted a few times on this topic but it's still bugging me so here I go again.
In my application I have two types of "user preference", the first being those needed by the business layer, the second being those required by the UI. To me these are distinct. Those "user preferences" required by the BLL must of course be accessable regardless of the intereface, so they should be stored on the server (in the database). Where as those required by the UI may be stored on the server (for web apps I guess) but could also be stored on the client (for win apps) in the form of application settings say.
I'm storing the users BLL prefs in a Profile table in the DB. The UI prefs are stored in application settings on the client. To present the configuration of these user preferences to user for editing I have two dialogs. One called Profile where the user can edit the settings for the his BLL preferences and one called Options for editing UI user preferences. Does this make sense? Also any good naming cons for the two types of preference anyone?
Who thinks I should just store all the prefs in the Profile table? Even if the options don't make sense for some interfaces (eg start miminized on the web)???
Anybody with experience with business layer user preferences (including user configurable defaults) please reply :-)
Thanks guys, George.
Hi George
It really depends on the app. I've used a combination of both at various times. So I don't think there is one definitive answer here as things tend to change over time.
If you store all the prefs in the db, and the connection goes down.....oops.
Even if the options don't make sense for some interfaces (eg start miminized on the web)??? Add more fields to Profile table e.g. UI type (Web, Win, Win Service, ..) , UserEditable, LoadStartUp......
You could use a tab control and combine the Preferences form.
Sorry I can't be more helpful
My rule of thumb:
As a starting point I usually use the config file for per users settings, and a db table for applcation wide settings. Also I keep any sensitive info in the db. I also tend to 'lazyload' my settings, e.g. I only load what I need to startup, and the rest I load as required.
George,
I've been down this road quite a few times as well and the fact that you are already differentiating between what I refer to as User Settings and Application Settings gives you a great head-start. I too consider User Settings to be those things, such as Language, that should be persisted as part of the application's data. Application Settings, to me, are those things that the drives the UI such as grid sorts & filters and are persisted locally although I have an application where I allow "roaming users" which saves the Application Settings to the server so that the user has the same settings when they access the app from a different system.
To make this work, I stole a page from the way MS has the Office apps setup in this regard. I have separate business objects for each "category" of settings. Each of these BO's can be bound to an individual tab in the Options dialog if you want. When the user hits the OK button to commit the Options dialog, the AcceptChanges method is called on each BO. This allows each to handle its persistance on its own. If I want to save both to the db, I can. If I want one to go to Isolated Storage or some other location while the other goes to the db, I can.
I find this approach fits right into the use of business objects and the framework we have in place and gives us the flexibility we need for our applications.
Hope that helps.
Copyright (c) Marimer LLC