Формат файла данных для толстого клиентского приложения .net

Question

Я прочитал множество рекомендаций по этому поводу, и мне просто любопытно, каким будет «современное состояние» для этого -

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

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

Итак, если яЕсли бы я хотел модернизировать это приложение, я бы, вероятно, предпочел бы использовать различные общие списки объектов для уровня данных в памяти, которые затем можно было бы преобразовать в двоичную сериализацию в файл.Но есть ли лучшие способы?Я знаю, что использование базы данных для файла позволило бы мне обновлять только определенные элементы, вместо того, чтобы заново сериализовать все это, но сейчас мне не приходится разбираться с головной болью, выясняя, какие элементы были изменены и нуждаются в обновлении и т. Д.И если я продолжу просто сериализовать все, есть ли лучшие или более стандартизированные / открытые способы сделать это - что-то вроде буферов протокола или bson приходит на ум.

Я посмотрю некоторые ответы и добавлю любые пояснения, если это необходимо.ТИА.

Answer 1

Вопрос помечен как «sqlite».Как будто ты уже решил, может быть, уже?: -)

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

SQLite - надежный, компактный, с неинвазивной установкой, и поставщик данных System.Data.SQLite хорош, а также поддерживает UDF, написанные на языке .NET.Это дало бы вашему приложению не только более детально адресуемое хранилище данных, но и другой набор возможностей и интеллекта, и поэтому было бы лучше, чем «пассивное» хранилище данных.

Я не использовал SQLite дляхранить изображения, поэтому я не могу комментировать это требование.

Answer 2

Если ваши данные «простые»: то есть табличные или иерархические (DAG) без сложных ссылок между объектами, то у вас есть довольно много вариантов.В этом случае обсуждение становится более «какой базы данных», то есть реляционной или документной основе.Выбор зависит от структуры данных, объема данных и т. Д. Я бы оценил Sqlite, sql server compact, буферы протокола googles и, возможно, некоторую реализацию nosql, такую ​​как ravendb.

Если ваши данные общиеГраф объектов (не ациклический граф) тогда вам не так повезло.Трудно реализовать что-либо, кроме прямой сериализации всего графа, когда вам нужно сохранить идентичность объектов.Еще большие трудности возникают, например, из-за ссылок на синглтоны (с которыми BinaryFormatter действительно справляется довольно хорошо).Общее решение - это просто запись в файл с помощью BinaryFormatter, но вы столкнетесь с тремя новыми проблемами: производительность, размер файла и совместимость формата файла.

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

Если вам нужен более гибкий формат, который позволяет использовать метаданные и т. Д., Я бы предложил использовать классы System.IO.Packaging для создания архивного файла OPC с вашими данными в PackagePart.

Answer 3

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