Похоже, что вы хотите BinaryFormatter. Это сохраняет нечитаемый двоичный файл. Одним из основных преимуществ этого метода для XmlSerialization (например) является то, что ваши свойства не должны быть общедоступными.
Однако я лично хотел бы отговорить вас от этой идеи. Я сам шел по этому пути, и в то время как его легко в краткосрочной перспективе, в конечном счете, в дороге много боли.
У вас будут серьезные проблемы с версией. Всякий раз, когда вы хотите обновить любой объект (скажем, добавить новое свойство), вам придется преобразовать все файлы.
Еще хуже, если вы хотите сделать это в одном приложении, вам понадобятся оба определения, доступные одновременно. Это приводит к абсурдистским определениям классов, такие как:
// my original object
class SavedObject
{
public string Data{get;set}
}
// needed to add a field for last edit
class SavedObject2
{
public DateTime LastEdit{get;set;}
public SavedObject2(SavedObject so){}
}
// need a small restructure so we can now have multiple datas
// 'data' is now obsolete
class SavedObject3
{
public List<string> DataList{get;set;}
public SavedObject3(SavedObject2 so){}
}
Serialising как средство упорства хорошо только в двух сценариях. Один, где вы знаете , данные никогда не будут меняться в определении (невероятно редко) и: два, где вы просто сохраняете данные примитивным способом (например, просто набор строк, которые затем преобразуются в классы).
Я серьезно рассмотрел бы использование базы данных. Если вы не обращаете внимания на административные обязанности, которые приходят с большинством баз данных, то рассмотрите возможность использования Sqlite, он небольшой, переносимый и очень простой для встраивания в приложение.
Я не вижу вопроса здесь, хотя я читал его ** дважды **! – gdoron
возможно Сериализация и StreamWriter? – Goanne
@gdoron Да, я тоже это прочитал и нашел, что это сбивает с толку, извините, мой плохой :) просто отредактировал его :) –