Могат ли обектите да се сериализират/десериализират в различни версии на рамка?

Трябва да сериализирам обект с помощта на BinaryFormatter с .NET 4.0 и да го изпратя по кабела (чрез SOAP като байтов масив) към уеб услуга, работеща под .NET 3.5. И обратно. Тествах този сценарий и изглежда, че работи добре.

Има един стар въпрос относно този сценарий на SO, че говори за .NET 1.x до 2.0, което не ме остави с много увереност относно подхода.

Така че работи в моята тестова система, но не мога да тествам всяка възможна вариация на обекта, така че имам нужда от някои теоретични основи.

Като правило, могат ли обектите да се сериализират/десериализират в различни версии на рамка? Това приет сценарий ли е или хак, който проработи в моя случай?


person AngryHacker    schedule 10.02.2012    source източник
comment
Какъв тип сериализация използвате (двоичен, XML, JSON и т.н.)?   -  person Justin Niessner    schedule 10.02.2012
comment
Мисля, че трябва да спреш да бъдеш AngryHacker и да станеш JollyHacker, за да работи това най-добре :)   -  person Mark Schultheiss    schedule 10.02.2012
comment
точно какъв сериализатор използвате? Има голямо значение при отговора на това   -  person Marc Gravell    schedule 10.02.2012
comment
Двоичният код не е достатъчен, за да се отговори на този въпрос. Множество сериализатори записват нетекстови изходни данни; някои ще работят добре тук (protobuf-net, BSON и т.н.) - а някои са едва надеждни дори на една версия на рамката (BinaryFormatter и т.н.). Кое точно?   -  person Marc Gravell    schedule 10.02.2012
comment
@MarcGravell Съжалявам, да форматиращ BinaryFormatter. Актуализиране на въпроса.   -  person AngryHacker    schedule 10.02.2012


Отговори (3)


Ако под „двоичен“ имате предвид BinaryFormatter, тогава той вече е изключително нетолерантен между версиите, тъй като е стриктно обвързан с метаданни за тип (освен ако не работите наистина усилено с персонализирани обвързвания). Като такъв, той е строго надежден само когато и двата края използват точно едни и същи реализации. Дори промяната на свойство към/от автоматично внедрено свойство е критична промяна.

Това не е недостатък на "binary", а функция на BinaryFormatter. Други бинарни сериализатори нямат този проблем. Например protobuf-net работи между ОС, между рамки и т.н. - тъй като форматът a: не се интересува от вашите конкретни типове, а b: е фиксиран към публикувана спецификация.

Ако в момента използвате BinaryFormatter за това: тогава IMO да, трябва изрично да тествате всеки API. Тъй като всеки тип може да промени детайлите на изпълнението. И за съжаление, тъй като BF има навика да извлича неочаквани данни (чрез събития и т.н.), дори това не е непременно достатъчно, за да потвърди реалното използване.

person Marc Gravell    schedule 10.02.2012
comment
Обектите, които пускам през кабела, са изолирани в отделен сбор (който е компилиран до .NET 3.5). И клиентът, и сървърът имат точното копие на сборката, така че неща като промени в свойствата не са проблем. Също така, обектите са чисти обекти за пренос на данни, напр. няма събития или нещо подобно. В безопасност ли съм при този сценарий? - person AngryHacker; 10.02.2012
comment
@AngryHacker Поздравявам доброто ви планиране и напредничаво мислене. Това всъщност ще ви изолира от свят на болка тук. С тази настройка очаквам да работи. Ще ме изненада, ако това не успее, но: понякога се случват изненади. - person Marc Gravell; 10.02.2012

Ако форматът за сериализиране е XML (SOAP) или JSON, той не би трябвало да работи без проблем. Не съм сигурен как би реагирал бинарен сериализиран обект.

person Sam Axe    schedule 10.02.2012

Най-големият проблем със сериализацията е, когато имате примитиви, които не съществуват. По дяволите, проблемът съществува при преминаване към определени типове в собствения код, така че не е уникален проблем, открит в услугите (предположение).

Като „правило“ можете да сериализирате между версиите на рамката и дори към клиенти, написани на Java, Delphi и COBOL (осигурена версия с възможност за уеб услуга – и при условие, че сте изложили сериализираните обекти по подходящ начин чрез крайна точка на услуга).

Опитвам се да мисля дали има някакви примитиви в .NET, които не са присъствали в 1.x, тъй като биха били проблематични. Както и всички нови рамкови обекти, които бихте могли да опитате да сериализирате. Имате много по-малко опасности с 2.0 (може би несъществуващ?)

Колкото по-"отворена" е вашата сериализация (т.е. стандарти като JSON, SOAP и т.н. - опростено: JSON или XML, поне в повечето случаи), толкова по-малка е вероятността да имате проблеми. И ако имате проблеми, можете да кодирате около автоматичните прокси сървъри и т.н. Докато преминавате към двоичен код, може да имате известна несъвместимост между обект, сериализиран в 4.0 с WCF и Remoting клиент.

person Gregory A Beamer    schedule 10.02.2012
comment
Аз сериализирам с бинарния сериализатор и предавам чрез SOAP. Можете ли да посочите пример (дори теоретичен), при който би имало несъвместимост? - person AngryHacker; 10.02.2012
comment
Не веднага. Ако сериализирате обектите на вашия домейн (а не неща от .NET Framework) и се придържате към примитиви, които съществуват от 1.x (например, избягвайте nullable типове), не мисля, че ще имате проблем, дори с двоична сериализация. По принцип, ако предавате състояние (основни обекти с гетери и сетери на свойства и не много друго) и се придържате към общи примитиви, трябва да сте добре. - person Gregory A Beamer; 10.02.2012
comment
И от архитектурна гледна точка можете да се върнете към базирана на SOAP крайна точка за вашите клиенти 1.x, ако сте се счупили извън простия режим. :-) ::: Трябва да харесам гъвкавостта на WCF. - person Gregory A Beamer; 10.02.2012
comment
Мисля, че грешно сте прочели въпроса ми. Нямам WCF или 1.x клиенти никъде в уравнението. Само стандартни уеб услуги, свързващи 3.5/4.0 части. - person AngryHacker; 10.02.2012