views:

775

answers:

4

I am working on a Silverlight client and associated ASP.NET web services (not WCF), and I need to implement some features containing user preferences such as a "favourite items" system and whether they'd like word-wrapping or not. In order to make a pleasant (rather than infuriating) user experience, I want to persist these settings across sessions. A brief investigation suggests that there are two main possibilities.

  1. Silverlight isolated storage
  2. ASP.NET-accessible database

I realise that option 2 is probably the best option as it ensures that even if a user disables isolated storage for Silverlight, their preferences still persist, but I would like to avoid the burden of maintaining a database at this time, and I like the idea that the preferences are available for loading and editing even when server connectivity is unavailable. However, I am open to reasoned arguments why it might be preferrable to take this hit now rather than later.

What I am looking for is suggestions on the best way to implement settings persistence, in either scenario. For example, if isolated storage is used, should I use an XML format, or some other file layout for persisting the settings; if the database approach is used, do I have to design a settings table or is there a built-in mechanism in ASP.NET to support this, and how do I serve the preferences to the client?

So:

Which solution is the better solution for user preference persistence? How might settings be persisted in that solution, and how might the client access and update them?

Prior Research

Note that I have conducted a little prior research on the matter and found the following links, which seem to advocate either solution depending on which article you read.

Update

It turns out that Microsoft have provided settings persistence in isolated storage as a built-in part of Silverlight (I somehow missed it until after implementing an alternative). My answer below has more details on this.

I'm keeping the question open as even though Microsoft provides client-side settings persistence, it doesn't necessarily mean this is the best approach for persisting user preferences and I'd like to canvas more opinions and suggestions on this.

A: 

I think in general the default would be to store on the server; only when there are specific compelling reasons to attempt to store on the client should we do so. The more you rely on storing in a medium you can't control, the more risk you take on.

That having been said, and setting myself on the "database" side of the argument, I would ask what the downside of a database is? You mentioned using XML - is your data only semi-structured? If so, why not store XML in a SQL database? Setting up something this simple would not generally be considered a "burden" by most standards. A simple web service could act as a go-between between your Silverlight client and the settings database.

Rex M
The burden of the database solution is that I am then responsible for the backing up and maintenance of that data.Also, I would be in control of the storage but not the connection to that storage (i.e. the Internet), so I see it as swapping one problem (not being in control of the user's machine and whether they permit Silverlight storage) to another (not being in control of whether my client is connected to my database).
Jeff Yates
+1  A: 

If it is an important feature for you that users have access to their preferences while offline, then it looks like isolated storage is the way to go for you. If it's more important that users be able to save preferences even if they have turned off isolated storage (is this really a problem? I'd be tempted to call YAGNI on this, but I'm not terribly experienced with the Silverlight platform...) then you need to host a database. If both are important, then you're probably looking at some kind of hybrid solution; using isolated storage if available, then falling back to a database.

In other words, I think the needs of your application are more important than some abstract best practice.

Greg Fleming
I tend to agree with you, Greg, but as I'm new to most of this, I wanted to canvas more experienced minds in case I was missing something. The way I see it is that the server is a good backup location for settings, but the client should have first class access all the time with the option to backup/restore from the server.
Jeff Yates
A: 

After investigating some more and implementing my own XML file-based settings persistence using IsolatedStorage, I discovered the IsolatedStorageSettings class and the IsolatedStorageSettings.ApplicationSettings object that is a key/value collection specifically for storing user-specific, application settings.

It all seems obvious now. Of course, in the long term, a mechanism for backing up and restoring settings using a server database would be a good enhancement to this client-side settings persistence.

Jeff Yates
A: 

This is a bit late but I have the same problem and found a nice reader/writer class to access Settings - http://yinyangme.com/blog/post/Settings-for-Silverlight-using-IsolatedStorageSettings.aspx

Rodney