Простой контроль версий файлов данных с DataContractSerializer

Question

Прочитав Data Contract Versioning, мы пришли к выводу, что это не совсем целая история. Например, что произойдет, если вы использовали ValueA, а в новой версии теперь называется ValueB и имеет другой тип, и вам нужно преобразовать ValueA в ValueB?

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

Решение, по которому мы остановились, заключается в том, чтобы сохранить поле «сохранено по версии» и после загрузки файлов вызывать программы конверсии, относящиеся к более старым версиям, по мере необходимости. Эти процедуры преобразования знают, как преобразовать XML для более старых данных в XML для новых данных.

Однако, как выясняется, DataContractSerializes requires the order of the elements to be exactly what it expects. Это означает, что наш процесс преобразования должен знать, чтобы вставить элементы в точно в нужное место. Это намного сложнее, чем просто добавление элемента с известным именем, если вы учитываете наследование. С наследованием вы не можете надежно или AddAfterSelfлюбое поле, просто потому, что рядом с этим новым полем нет ни одного поля.

Оставляя в стороне причины, почему DataContractSerializer был сделан настолько строгим, можете ли вы предложить варианты вокруг этого? Возможно, замечательная статья о том, как оставаться обратно совместимой с очень старыми контрактами данных, которая не становится громоздкой в ​​тот момент, когда вы сделали 100-е изменение в формате.

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

Answer 1

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

В случае нарушения изменений контракта вы, вероятно, лучше создали бы новую версию контракта (например, с использованием нового пространства имен - общим соглашением является использование суффикса yyyy/mm, например http://mycompany.com/myservices/2009/10).

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

Answer 2

Через год я должен сказать, что DataContractSerializer действительно засасывает версию. Это слишком жестко. Это действительно предназначено для контрактов, которые вряд ли будут меняться, а затем только по определенным причинам. Вам нужно сделать дополнительную работу, чтобы использовать ее, чтобы ускорить ее работу - например, KnownTypeAttribute. Я бы рекомендовал это только в том случае, если вам требуется относительно быстрая сериализация - что, возможно, весьма важно для того, для чего она предназначена.

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

Теперь, если бы я мог опубликовать его здесь ... Это примерно 5x-10x медленнее, чем DataContractSerializer.