Сериализация списка объектов с использованием Protobuf-net - PullRequest
Новая
       17

Сериализация списка объектов с использованием Protobuf-net

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

Я пытался выполнить некоторую двоичную сериализацию в файл, и protobuf-net кажется хорошей альтернативой. Я немного застрял в начале, хотя. Поскольку я хочу отделить определение классов от фактической сериализации, я не использую атрибуты, но предпочитаю использовать файлы .proto, у меня есть структура для объекта (я думаю) 

message Post {

  required uint64 id = 1;

  required int32 userid = 2;

  required string status= 3;

  required datetime created = 4;

  optional string source= 5;

}

(действительно ли дата / время действительны или я должен использовать тики как int64?)

но я застрял на том, как использовать protogen, а затем сериализовать IEnumerable of Post в файл и прочитать его обратно. Любая помощь будет оценена

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

1 Ответ

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

Re DateTime ... это не стандартный прототип; Я добавил BCL.DateTime (или аналогичный) в свою собственную библиотеку, которая предназначена для соответствия внутренней сериализации, которую использует protobuf-net для DateTime, но я вполне уверен, что я (пока) не обновил код Генератор, чтобы обнаружить это как особый случай. Было бы довольно легко добавить, если вы хотите, чтобы я попробовал ... Если вы хотите максимальной переносимости, подход в стиле «галочки» может быть прагматичным. Дайте мне знать ...

Повторная сериализация в файл - если она должна быть примерно такой же, как в примере Getting Started , но учтите, что protobuf-net хочет работать с данными, которые он может восстановить; просто IEnumerable<T> может вызвать проблемы - хотя IList<T> должно быть в порядке (по умолчанию List<T> будет использоваться как конкретный тип при реконструкции).

В случае повреждения - возможно, используйте SerializeWithLengthPrefix - тогда он может обнаруживать проблемы даже на границе сообщения (где они в противном случае не обнаруживаются как EOF). Это (как следует из названия) сначала записывает длину, поэтому она знает, достаточно ли у нее данных (через DeserializeWithLengthPrefix). В качестве альтернативы зарезервируйте первые [n] байтов в вашем файле для хэша / контрольной суммы. Запишите этот пробел, затем данные, вычислите хэш / контрольную сумму и перезапишите начало. Проверять во время десериализации. Гораздо больше работы.

...