Сохранение пользовательских настроек в Silverlight - PullRequest
8 голосов
/ 05 мая 2009

Я работаю над клиентом Silverlight и соответствующими веб-службами ASP.NET (не WCF), и мне нужно реализовать некоторые функции, содержащие пользовательские настройки, такие как система «избранных элементов», и хотят ли они переноса слов или не. Чтобы сделать пользовательский опыт приятным (а не приводящим в бешенство), я хочу сохранить эти настройки во время сеансов. Краткое исследование показывает, что есть две основные возможности.

  1. Silverlight изолированное хранилище
  2. ASP.NET-доступная база данных

Я понимаю, что вариант 2, вероятно, является наилучшим вариантом, поскольку он гарантирует, что даже если пользователь отключит изолированное хранилище для Silverlight, его предпочтения сохранятся, но я бы хотел избежать бремени поддержки базы данных в настоящее время, и я Например, идея о том, что настройки доступны для загрузки и редактирования, даже когда подключение к серверу недоступно. Тем не менее, я открыт для аргументированных аргументов, почему может быть предпочтительнее принять этот удар сейчас, а не позже.

Что я ищу, так это предложения о том, как наилучшим образом реализовать сохранение настроек в любом из этих сценариев. Например, если используется изолированное хранилище, должен ли я использовать формат XML или какой-либо другой формат файла для сохранения настроек; если используется подход с использованием базы данных, нужно ли разрабатывать таблицу параметров или в ASP.NET имеется встроенный механизм для поддержки этого и как мне обслуживать предпочтения клиента?

Итак:

Какое решение является лучшим решением для сохранения предпочтений пользователя? Как сохранить настройки в этом решении и как клиент может получить к ним доступ и обновить их?

Предыдущие исследования

Обратите внимание, что я провел небольшое предварительное исследование по этому вопросу и нашел следующие ссылки, которые, по-видимому, поддерживают любое решение в зависимости от того, какую статью вы прочитали.

Обновление

Оказывается, Microsoft предоставила постоянство настроек в изолированном хранилище как встроенную часть Silverlight (я как-то пропустил его, пока не реализовал альтернативу). Мой ответ ниже содержит более подробную информацию по этому вопросу.

Я держу вопрос открытым, поскольку, несмотря на то, что Microsoft обеспечивает постоянство настроек на стороне клиента, это не обязательно означает, что это лучший подход для сохранения пользовательских предпочтений, и я хотел бы высказать больше мнений и предложений по этому вопросу.

Ответы [ 3 ]

2 голосов
/ 07 мая 2009

Проведя дополнительные исследования и реализовав свое собственное постоянство настроек на основе файлов XML с использованием IsolatedStorage , я обнаружил класс IsolatedStorageSettings и объект IsolatedStorageSettings.ApplicationSettings , которые представляет собой набор ключей / значений, предназначенный для хранения пользовательских настроек приложения.

Теперь все кажется очевидным. Конечно, в долгосрочной перспективе механизм резервного копирования и восстановления настроек с использованием серверной базы данных будет хорошим улучшением для этой персистентности настроек на стороне клиента.

1 голос
/ 06 мая 2009

Если для вас важно, чтобы пользователи имели доступ к своим предпочтениям в автономном режиме, то, похоже, вам подходит изолированное хранилище. Если более важно, чтобы пользователи могли сохранять настройки, даже если они отключили изолированное хранилище (это действительно проблема? У меня возникнет соблазн позвонить по этому поводу в YAGNI, но я не очень разбираюсь в платформе Silverlight) .) тогда вам нужно разместить базу данных. Если оба важны, то вы, вероятно, смотрите на какое-то гибридное решение; используя изолированное хранилище, если оно доступно, затем возвращаясь к базе данных.

Другими словами, я думаю, что потребности вашего приложения более важны, чем некоторая абстрактная лучшая практика.

1 голос
/ 06 мая 2009

Я думаю, что по умолчанию будет храниться на сервере; мы можем делать это только в том случае, если есть конкретные веские причины пытаться хранить данные на клиенте. Чем больше вы полагаетесь на хранение в среде, которую вы не можете контролировать, тем больше вы рискуете.

С учетом сказанного, и, ставя себя на сторону аргумента "базы данных", я спрашиваю, что является недостатком базы данных? Вы упомянули об использовании XML - ваши данные только частично структурированы? Если так, то почему бы не хранить XML в базе данных SQL? Настройка чего-то такого простого, как правило, не будет считаться «обузой» по большинству стандартов. Простой веб-сервис может выступать посредником между вашим клиентом Silverlight и базой данных настроек.

...