Лучший способ хранить данные локально в .NET (C #) - PullRequest
Новая
       61

Лучший способ хранить данные локально в .NET (C #)

66 голосов
/ 21 декабря 2009

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

Было бы довольно просто, если бы я использовал плоские файлы, поскольку данные на самом деле не нужно защищать (они будут храниться только на этом ПК). Варианты, которые я считаю, таковы:

  • Плоские файлы
  • XML
  • БД SQL

Плоские файлы требуют немного больше усилий для поддержки (нет встроенных классов, подобных XML), однако я раньше не использовал XML, и SQL кажется слишком сложным для этой относительно простой задачи.

Есть ли другие пути, которые стоит изучить? Если нет, то какое из них является лучшим решением?

Edit: чтобы добавить немного больше данных к проблеме, в основном, единственное, что я хотел бы сохранить, это словарь, который выглядит так 

Dictionary<string, List<Account>>

, где Учетная запись - другой пользовательский тип.

Буду ли я сериализовать dict как xmlroot, а затем тип учетной записи как атрибуты?

Обновление 2:

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

Насколько я понимаю, цель здесь состоит в том, чтобы попытаться закончить с этим: 

<Username1>
    <Account1>
        <Data1>data1</Data1>
        <Data2>data2</Data2>
    </Account1>
</Username1>
<Username2>
    <Account1>
        <Data1>data1</Data1>
        <Data2>data2</Data2>
    </Account1>
    <Account2>
        <Data1>data1</Data1>
        <Data2>data2</Data2>
    </Account2>
 </Username2>

Как вы можете видеть, иерархия

  • Имя пользователя (строка с надписью)>
  • Аккаунт (каждый аккаунт в Списке)>
  • Данные учетной записи (т.е. свойства класса).

Получение этого макета из Dictionary<Username, List<Account>> - хитрый момент, и суть этого вопроса.

Существует множество ответов «как делать» здесь по поводу сериализации, и это моя вина, так как я не делал это раньше, но сейчас я ищу определенное решение.

Ответы [ 19 ]

3 голосов
/ 21 декабря 2009

Многие ответы в этой теме пытаются переоценить решение. Если я прав, вы просто хотите сохранить пользовательские настройки.

Для этого используйте файл .ini или файл App.Config.

Если я не прав, и вы храните данные, которые представляют собой нечто большее, чем просто настройки, используйте текстовый файл в формате CSV. Это быстро и легко без издержек на XML. Людям нравится делать это, потому что они не такие элегантные, не очень хорошо масштабируются и выглядят не так хорошо, как резюме, но это может быть лучшим решением для вас, в зависимости от того, что вам нужно.

2 голосов
/ 21 декабря 2009

Я сделал несколько «автономных» приложений с локальным хранилищем данных. Я думаю, что лучше всего использовать SQL Server Compact Edition (ранее известный как SQLAnywhere).

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

0 голосов
/ 12 мая 2017

По моему опыту, в большинстве случаев достаточно JSON в файле (в основном вам нужно хранить массив или объект или просто одно число или строку). Мне редко нужен SQLite (который требует больше времени для его настройки и использования, в большинстве случаев это излишне).

0 голосов
/ 21 декабря 2009

Мое первое желание - база данных доступа. Файлы .mdb хранятся локально и могут быть зашифрованы, если это необходимо. Хотя XML или JSON также подойдут для многих сценариев. Плоские файлы, которые я бы использовал только для чтения, не для поиска (только для чтения). Я предпочитаю формат CSV, чтобы установить ширину.

0 голосов
/ 21 декабря 2009

Это зависит от количества данных, которые вы хотите сохранить. В действительности нет разницы между плоскими файлами и XML. XML, вероятно, предпочтительнее, поскольку он обеспечивает структуру документа. На практике

Последний вариант, который сейчас используют многие приложения, - это реестр Windows. Я лично не рекомендую это (переполнение реестра, коррупция, другие потенциальные проблемы), но это вариант.

0 голосов
/ 21 декабря 2009

Не зная, как выглядят ваши данные, то есть сложность, размер и т. Д. XML прост в обслуживании и легко доступен. Я бы НЕ использовал базу данных Access, и простые файлы труднее поддерживать в течение длительного времени, особенно если вы имеете дело с более чем одним полем / элементом данных в вашем файле.

Я ежедневно работаю с большими плоскими фидами данных в больших количествах, и, несмотря на крайний пример, данные с плоскими файлами гораздо сложнее поддерживать, чем фиды XML-данных, которые я обрабатываю.

Простой пример загрузки данных XML в набор данных с использованием C #: 

DataSet reportData = new DataSet();

reportData.ReadXml(fi.FullName);

Вы также можете проверить LINQ to XML в качестве опции для запроса данных XML ...

НТН ...

0 голосов
/ 21 декабря 2009

Будьте проще - как вы сказали, достаточно плоского файла. Используйте плоский файл.

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

0 голосов
/ 21 декабря 2009

В зависимости от сложности объекта вашей учетной записи, я бы рекомендовал либо XML, либо плоский файл.

Если для каждой учетной записи нужно сохранить только пару значений, вы можете сохранить их в файле свойств, например так: 

account.1.somekey=Some value
account.1.someotherkey=Some other value
account.1.somedate=2009-12-21
account.2.somekey=Some value 2
account.2.someotherkey=Some other value 2

... и так далее. Чтение из файла свойств должно быть легким, поскольку оно отображается непосредственно в строковый словарь.

Относительно того, где хранить этот файл, наилучшим вариантом будет сохранение в папке AppData внутри подпапки вашей программы. Это место, где текущие пользователи всегда будут иметь доступ к записи, и сама ОС защищена от других пользователей.

0 голосов
/ 21 декабря 2009

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

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

Страница:
...