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

Я бы сохранил файл как JSON. Поскольку вы храните словарь, который представляет собой просто список пар имя / значение, то это в значительной степени то, для чего был разработан json.
Существует довольно много приличных бесплатных json-библиотек .NET - вот one, но вы можете найти полный список по первой ссылке.

Это действительно зависит от того, что вы храните. Если вы говорите о структурированных данных, то вам подойдет XML или очень легкая СУБД SQL, такая как SQLite или SQL Server Compact Edition. Решение SQL становится особенно привлекательным, если размер данных превышает тривиальный размер.

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

Все вышеперечисленное является хорошими ответами и в целом решает проблему.

Если вам нужен простой и бесплатный способ масштабирования до миллионов фрагментов данных, попробуйте проект ESENT Managed Interface на GitHub или из NuGet.

ESENT - это встраиваемый механизм хранения баз данных (ISAM), который является частью Windows. Он обеспечивает надежное, синхронизированное, одновременное и высокопроизводительное хранилище данных с блокировкой на уровне строк, журналированием с упреждающей записью и изоляцией моментальных снимков. Это управляемая оболочка для ESENT Win32 API.

У него есть объект PersistentDictionary, который довольно прост в использовании. Думайте об этом как об объекте Dictionary (), но он автоматически загружается и сохраняется на диск без дополнительного кода.

Например:

/// <summary>
/// Ask the user for their first name and see if we remember 
/// their last name.
/// </summary>
public static void Main()
{
    PersistentDictionary<string, string> dictionary = new PersistentDictionary<string, string>("Names");
    Console.WriteLine("What is your first name?");
    string firstName = Console.ReadLine();
    if (dictionary.ContainsKey(firstName))
    {
        Console.WriteLine("Welcome back {0} {1}", firstName, dictionary[firstName]);
    }
    else
    {
        Console.WriteLine("I don't know you, {0}. What is your last name?", firstName);
        dictionary[firstName] = Console.ReadLine();
    }

Чтобы ответить на вопрос Джорджа:

Поддерживаемые типы ключей

В качестве ключей словаря поддерживаются только эти типы:

Логический байт Int16 UInt16 Int32 UInt32 Int64 UInt64 Float Double Guid DateTime TimeSpan String

Поддерживаемые типы значений

Значения словаря могут быть любыми из типов ключей, допускающими значение NULL версиями типов ключей, Uri, IPAddress или сериализуемой структурой. Структура считается сериализуемой, только если она соответствует всем этим критериям:

• Структура помечена как сериализуемая. • Каждый член структуры может быть: 1. Примитивным типом данных (например, Int32) 2. Строкой, Uri или IP-адресом 3. Сериализуемой структурой.

Или, другими словами, сериализуемая структура не может содержать никаких ссылок на объект класса. Это сделано для сохранения согласованности API. Добавление объекта в PersistentDictionary создает копию объекта посредством сериализации. Изменение исходного объекта не приведет к изменению копии, что приведет к запутанному поведению. Чтобы избежать этих проблем, PersistentDictionary будет принимать только типы значений в качестве значений.

Можно сериализовать [сериализуемый] struct Good {public DateTime? Получила; публичная строка Имя; публичная десятичная цена; общедоступный Uri Url; }

Невозможно сериализовать [Serializable] struct Bad {public byte [] Data; // массивы не поддерживаются public Exception Error; // ссылочный объект}

XML прост в использовании благодаря сериализации. Используйте Изолированное хранилище.

См. Также Как решить, где хранить состояние для каждого пользователя? Реестр? Данные приложения? Изолированное хранилище?

public class UserDB 
{
    // actual data to be preserved for each user
    public int A; 
    public string Z; 

    // metadata        
    public DateTime LastSaved;
    public int eon;

    private string dbpath; 

    public static UserDB Load(string path)
    {
        UserDB udb;
        try
        {
            System.Xml.Serialization.XmlSerializer s=new System.Xml.Serialization.XmlSerializer(typeof(UserDB));
            using(System.IO.StreamReader reader= System.IO.File.OpenText(path))
            {
                udb= (UserDB) s.Deserialize(reader);
            }
        }
        catch
        {
            udb= new UserDB();
        }
        udb.dbpath= path; 

        return udb;
    }


    public void Save()
    {
        LastSaved= System.DateTime.Now;
        eon++;
        var s= new System.Xml.Serialization.XmlSerializer(typeof(UserDB));
        var ns= new System.Xml.Serialization.XmlSerializerNamespaces();
        ns.Add( "", "");
        System.IO.StreamWriter writer= System.IO.File.CreateText(dbpath);
        s.Serialize(writer, this, ns);
        writer.Close();
    }
}

Я рекомендую класс чтения / записи XML для файлов, потому что он легко сериализуется.

Сериализация в C #

Сериализация (известная как травление в Python) - это простой способ преобразовать объект в двоичное представление, которое затем может быть, например, записываются на диск или отправляются по сети.

Это полезно, например, для удобного сохранения настроек в файл.

Вы можете сериализовать свои собственные классы, если пометите их атрибутом [Serializable]. Это сериализует все члены класса, кроме отмеченных как [NonSerialized].

Ниже приведен код, показывающий, как это сделать:

using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;


namespace ConfigTest
{ [ Serializable() ]

    public class ConfigManager
    {
        private string windowTitle = "Corp";
        private string printTitle = "Inventory";

        public string WindowTitle
        {
            get
            {
                return windowTitle;
            }
            set
            {
                windowTitle = value;
            }
        }

        public string PrintTitle
        {
            get
            {
                return printTitle;
            }
            set
            {
                printTitle = value;
            }
        }
    }
}

Затем вы, возможно, в ConfigForm, вызываете свой класс ConfigManager и сериализуете его!

public ConfigForm()
{
    InitializeComponent();
    cm = new ConfigManager();
    ser = new XmlSerializer(typeof(ConfigManager));
    LoadConfig();
}

private void LoadConfig()
{     
    try
    {
        if (File.Exists(filepath))
        {
            FileStream fs = new FileStream(filepath, FileMode.Open);
            cm = (ConfigManager)ser.Deserialize(fs);
            fs.Close();
        } 
        else
        {
            MessageBox.Show("Could not find User Configuration File\n\nCreating new file...", "User Config Not Found");
            FileStream fs = new FileStream(filepath, FileMode.CreateNew);
            TextWriter tw = new StreamWriter(fs);
            ser.Serialize(tw, cm);
            tw.Close();
            fs.Close();
        }    
        setupControlsFromConfig();
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

После того, как он был сериализован, вы можете вызвать параметры вашего файла конфигурации, используя cm.WindowTitle и т. Д.

Я обнаружил, что если ваша коллекция становится слишком большой, сериализация Xml выполняется довольно медленно. Другой вариант сериализации вашего словаря - это «свернуть свой собственный» с помощью BinaryReader и BinaryWriter.

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

class Account
{
    public string AccountName { get; set; }
    public int AccountNumber { get; set; }

    internal void Serialize(BinaryWriter bw)
    {
        // Add logic to serialize everything you need here
        // Keep in synch with Deserialize
        bw.Write(AccountName);
        bw.Write(AccountNumber);
    }

    internal void Deserialize(BinaryReader br)
    {
        // Add logic to deserialize everythin you need here, 
        // Keep in synch with Serialize
        AccountName = br.ReadString();
        AccountNumber = br.ReadInt32();
    }
}


class Program
{
    static void Serialize(string OutputFile)
    {
        // Write to disk 
        using (Stream stream = File.Open(OutputFile, FileMode.Create))
        {
            BinaryWriter bw = new BinaryWriter(stream);
            // Save number of entries
            bw.Write(accounts.Count);

            foreach (KeyValuePair<string, List<Account>> accountKvp in accounts)
            {
                // Save each key/value pair
                bw.Write(accountKvp.Key);
                bw.Write(accountKvp.Value.Count);
                foreach (Account account in accountKvp.Value)
                {
                    account.Serialize(bw);
                }
            }
        }
    }

    static void Deserialize(string InputFile)
    {
        accounts.Clear();

        // Read from disk
        using (Stream stream = File.Open(InputFile, FileMode.Open))
        {
            BinaryReader br = new BinaryReader(stream);
            int entryCount = br.ReadInt32();
            for (int entries = 0; entries < entryCount; entries++)
            {
                // Read in the key-value pairs
                string key = br.ReadString();
                int accountCount = br.ReadInt32();
                List<Account> accountList = new List<Account>();
                for (int i = 0; i < accountCount; i++)
                {
                    Account account = new Account();
                    account.Deserialize(br);
                    accountList.Add(account);
                }
                accounts.Add(key, accountList);
            }
        }
    }

    static Dictionary<string, List<Account>> accounts = new Dictionary<string, List<Account>>();

    static void Main(string[] args)
    {
        string accountName = "Bob";
        List<Account> newAccounts = new List<Account>();
        newAccounts.Add(AddAccount("A", 1));
        newAccounts.Add(AddAccount("B", 2));
        newAccounts.Add(AddAccount("C", 3));
        accounts.Add(accountName, newAccounts);

        accountName = "Tom";
        newAccounts = new List<Account>();
        newAccounts.Add(AddAccount("A1", 11));
        newAccounts.Add(AddAccount("B1", 22));
        newAccounts.Add(AddAccount("C1", 33));
        accounts.Add(accountName, newAccounts);

        string saveFile = @"C:\accounts.bin";

        Serialize(saveFile);

        // clear it out to prove it works
        accounts.Clear();

        Deserialize(saveFile);
    }

    static Account AddAccount(string AccountName, int AccountNumber)
    {
        Account account = new Account();
        account.AccountName = AccountName;
        account.AccountNumber = AccountNumber;
        return account;
    }
}

Четвертый вариант из упомянутых вами - двоичные файлы. Хотя это звучит загадочно и сложно, с API сериализации в .NET это действительно просто.

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

Для двоичной сериализации класса он должен быть помечен атрибутом [Serializable] или реализован ISerializable.

Вы можете сделать что-то подобное с XML, хотя там интерфейс называется IXmlSerializable, а атрибуты - [XmlRoot] и другие атрибуты в пространстве имен System.Xml.Serialization.

Если вы хотите использовать реляционную базу данных, SQL Server Compact Edition бесплатен, очень легкий и основан на одном файле.

Только что закончил кодирование хранилища данных для моего текущего проекта. Вот мои 5 центов.

Я начал с двоичной сериализации. Это было медленно (около 30 секунд для загрузки 100 000 объектов), а также создавало довольно большой файл на диске. Однако для реализации мне потребовалось несколько строк кода, и все мои потребности в хранилище были покрыты. Чтобы повысить производительность, я перешел на настраиваемую сериализацию. Нашел фреймворк FastSerialization Тимом Хейнсом в Code Project. Действительно, он в несколько раз быстрее (12 секунд на загрузку, 8 секунд на сохранение, 100К записей) и занимает меньше места на диске. Фреймворк построен на методе, описанном GalacticJello в предыдущем посте.

Затем я перешел на SQLite и смог получить в 2 или 3 раза более высокую производительность - 6 секунд для загрузки и 4 секунды для сохранения, 100K записей. Он включает анализ таблиц ADO.NET по типам приложений. Это также дало мне намного меньший файл на диске. В этой статье объясняется, как добиться максимальной производительности от ADO.NET: http://sqlite.phxsoftware.com/forums/t/134.aspx. Создание операторов INSERT - очень плохая идея. Вы можете догадаться, как я узнал об этом. :) Действительно, реализация SQLite заняла у меня довольно много времени плюс тщательное измерение времени, которое уходит почти на каждую строчку кода.

Первое, на что я обращаю внимание, - это база данных. Однако сериализация - это вариант. Если вы выберете двоичную сериализацию, я бы избегал BinaryFormatter - он имеет тенденцию злиться между версиями, если вы меняете поля и т. Д. Xml через XmlSerialzier подойдет, и может быть рядом совместим (т.е. с теми же определениями классов) с protobuf-net, если вы хотите попробовать двоичную сериализацию на основе контрактов (что дает вам сериализатор плоских файлов без каких-либо усилий).

Если ваши данные сложны, их много или вам нужно запрашивать их локально, то объектные базы данных могут быть подходящим вариантом. Я бы посоветовал посмотреть Db4o или Карвонит.

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

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

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

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

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

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

DataSet reportData = new DataSet();

reportData.ReadXml(fi.FullName);

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

HTH ...

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

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

В зависимости от сложности объекта вашей учетной записи я бы рекомендовал либо 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 внутри подпапки вашей программы. Это место, где текущие пользователи всегда будут иметь доступ для записи, и оно защищено от других пользователей самой ОС.

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

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

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

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

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

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

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

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