我正在开发 Silverlight 客户端和关联的 ASP.NET Web 服务（不是 WCF），并且我需要实现一些包含用户首选项的功能，例如“最喜欢的项目”系统以及他们是否喜欢自动换行。 为了创造愉快（而不是令人恼火）的用户体验，我想在会话中保留这些设置。 一项简短的调查表明，主要有两种可能性。
- Silverlight 独立存储
- ASP.NET 可访问的数据库
我意识到选项 2 可能是最好的选择，因为它确保即使用户禁用 Silverlight 的独立存储，他们的首选项仍然存在，但我想避免维护数据库的负担此时，我喜欢这样的想法：即使服务器连接不可用，也可以加载和编辑首选项。 然而，我愿意接受合理的论点，为什么现在接受这次打击比以后接受打击更好。
我正在寻找的是有关在任一情况下实现设置持久性的最佳方法的建议。 例如，如果使用独立存储，我应该使用 XML 格式还是其他文件布局来保存设置？ 如果使用数据库方法，我是否必须设计一个设置表，或者 ASP.NET 中是否有内置机制来支持此操作，以及如何向客户端提供首选项？
那么：
哪种解决方案对于用户偏好持久化来说是更好的解决方案？ 如何在该解决方案中保留设置，以及客户端如何访问和更新它们？
先前的研究
请注意，我之前对此事进行了一些研究，并找到了以下链接，这些链接似乎提倡任一解决方案，具体取决于您阅读的文章。
更新
事实证明，Microsoft 已经在独立存储中提供了设置持久性，作为 Silverlight 的内置部分（我不知何故错过了它，直到实现替代方案之后）。 我在下面的回答对此有更多详细信息。
我保持这个问题的开放性，因为即使微软提供了客户端设置持久性，但这并不一定意味着这是持久用户首选项的最佳方法，我想就此征求更多意见和建议。
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.
- Silverlight isolated storage
- 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.
发布评论
评论（3）
在进行更多调查并使用 IsolatedStorage，我发现了IsolatedStorageSettings 类和 IsolatedStorageSettings.ApplicationSettings 对象，它是专门用于存储特定于用户的应用程序设置的键/值集合。
现在一切似乎都很明显了。 当然，从长远来看，使用服务器数据库备份和恢复设置的机制将是对客户端设置持久性的良好增强。
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.
我认为一般来说默认是存储在服务器上； 只有当有特定的令人信服的理由尝试在客户端上存储时，我们才应该这样做。 您越依赖于无法控制的介质中的存储，您承担的风险就越大。
话虽如此，并将自己置于争论的“数据库”方面，我想问数据库的缺点是什么？ 您提到使用 XML - 您的数据只是半结构化的吗？ 如果是这样，为什么不将 XML 存储在 SQL 数据库中呢？ 按照大多数标准，设置如此简单的东西通常不会被视为“负担”。 一个简单的 Web 服务可以充当 Silverlight 客户端和设置数据库之间的中间人。
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.
如果用户在离线状态下访问自己的偏好设置对您来说是一项重要功能，那么独立存储似乎是您的最佳选择。 如果更重要的是用户即使关闭了独立存储也能够保存首选项（这真的是一个问题吗？我很想为此致电 YAGNI，但我对 Silverlight 平台没有太多经验。） .) 那么你需要托管一个数据库。 如果两者都很重要，那么您可能正在考虑某种混合解决方案； 使用隔离存储（如果可用），然后回退到数据库。
换句话说，我认为您的应用程序的需求比一些抽象的最佳实践更重要。
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.