в своей программе я сохраняю данные(точнее объект) в файле, предварительно произведя сериализацию.
класс, экземпляр которого я сериализую
namespace PDU
{
[Serializable]
public class PDUFlashSlot : Library.UserSerialize.UserSerialize, ISerializable
{
...................
}
}
Сериализация
PDUFlashSlot data;
............
BinaryFormatter ser = new BinaryFormatter();
ser.Serialize(file , data);
десериализация
BinaryFormatter ser = new BinaryFormatter();
PDUFlashSlot data= (PDUFlashSlot)ser.Deserialize(file);
Программа получила развитие, соотвественно проект разросся, я решил навести порядок в проекте (конечно лучше бы всем этим начал заниматься с самого начала )
Вобщем начал распихивать классы реализованные ранее по разным namespace.
перенес описание класса PDUFlashSlot в
namespace Library
{
[Serializable]
public class PDUFlashSlot : Library.UserSerialize.UserSerialize, ISerializable
{
...................
}
}
В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU.
Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?
Здравствуйте, BUTEK, Вы писали:
BUT>В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU. BUT>Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?
Плавали, знаем Для решения проблемы нужно сделать свою реализацию класса SerializationBinder и подсунуть её форматтеру с помощью свойства Binder. Вообще из-за этого гемора я недолюбливаю бинарную сериализацию...
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, BUTEK, Вы писали:
BUT>>В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU. BUT>>Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?
K>Плавали, знаем Для решения проблемы нужно сделать свою реализацию класса SerializationBinder и подсунуть её форматтеру с помощью свойства Binder. Вообще из-за этого гемора я недолюбливаю бинарную сериализацию...
а чем порекомендуете пользоваться для хранения даных?
Здравствуйте, <Аноним>, Вы писали:
А>а чем порекомендуете пользоваться для хранения даных?
Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.
Со своей стороны посоветую в этом формате хранить версию формата (пока что 1.0) и предусмотреть, насколько это позволяет фантазия, возможность расширения формата, так, чтобы будущие изменения не нарушили его стройность и логичность.
Здравствуйте, AndrewVK, Вы писали:
AVK>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.
+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке. Даже XML-сериализация куда лучше, т.к. в крайнем случае при изменении схемы на данные можно накатить XSLT и привести их формат к пригодному для загрузки. Ну и, как тут справедливо заметили, обязательно нужно предусмотреть наличие неизменяемого заголовка с версией формата — по ней можно будет определить, какой парсер использовать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, AndrewVK, Вы писали:
AVK>>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.
PD>Со своей стороны посоветую в этом формате хранить версию формата (пока что 1.0) и предусмотреть, насколько это позволяет фантазия, возможность расширения формата, так, чтобы будущие изменения не нарушили его стройность и логичность.
Версия у меня как раз есть, и формат с помощью пользовательской сериализации я без проблем менял уже несколько раз.
Структуру данных продумать за ранее не могу, потомучто струткура сильно зависит от устройтсва с которого я читаю данные, разговоры на тему давайте жить дружно и совместными усилиями проработаем структуру хранения, обычно заканчиваются :"Ну ты понимаешь у нас железка ресурс ограниченый, а у тебя PC. Да и мы не виноваты, сейчас сказали сделать так, завтра по другому...."
Вопрос был не в этом, а в том что я перенес описание класса из одного namespace в другой
Здравствуйте, koandrew, Вы писали:
AVK>>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.
K>+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке.
Странная причина. У бинарного формата есть, во-первых, свои преимущества: а во-вторых, …
K>Даже XML-сериализация куда лучше, т.к. в крайнем случае при изменении схемы на данные можно накатить XSLT и привести их формат к пригодному для загрузки. Ну и, как тут справедливо заметили, обязательно нужно предусмотреть наличие неизменяемого заголовка с версией формата — по ней можно будет определить, какой парсер использовать.
…при наличии "неизменяемого заголовка" — выбор формата на самом деле дело уже двадцать пятое. В случае xml точно такой же заголовок с версией потребуется, что бы узнать каким образом что трансформировать. Xml конечно удобно, но двоичный формат компактен — в каждом случае можно выбрать что либо самое подходящее, а вот система: некий заголовок с версией и, возможно, какой-то дополнительной метаинформацией, — штука полезная при любом формате.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
K>>+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке.
_FR>Странная причина. У бинарного формата есть
Ты вообще внимательно сообщение прочел?
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
K>>>+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке. _FR>>Странная причина. У бинарного формата есть AVK>Ты вообще внимательно сообщение прочел?
Я как-то и представить не мог, что загвоздка не в слове "бинарная", а в термине предлагаемой фреймворком технологии — ты же это имеешь в виду?
И бинарную сериализацию можно "готовить" правильно, достаточно (хотя вариантов много) сериализуемые данные хранить в контейнере с версией и метаданными. Достаточно понимать, что если такой-то тип у нас сериализуем, то или мы сериализуем его "вручную" через конструктор и прочее или используем автоматику и лишь добавляем данные (поля) и не имеем права их удалять. С самой по себе "бинарной сериализуцией" при правильном подходе проблем тоже нет никаких (кроме сторонних вроде некоторой избыточности).
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
FR>Я как-то и представить не мог, что загвоздка не в слове "бинарная", а в термине предлагаемой фреймворком технологии — ты же это имеешь в виду?
И не только я.
_FR>И бинарную сериализацию можно "готовить" правильно, достаточно (хотя вариантов много) сериализуемые данные хранить в контейнере с версией и метаданными.
Точно топик не читал.
BinaryFormatter ser = new BinaryFormatter();
ser.Serialize(file , data);
Речь, как видишь, не о бинарном формате вообще, а о вполне конкетном BinaryFormatter
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
_FR>>И бинарную сериализацию можно "готовить" правильно, достаточно (хотя вариантов много) сериализуемые данные хранить в контейнере с версией и метаданными. AVK>Точно топик не читал.
Читал. Если бы потрудился более конкретно указать на то, что имеешь в виду, возможно я скорее бы тебя понял.
AVK>
AVK>BinaryFormatter ser = new BinaryFormatter();
AVK>ser.Serialize(file , data);
AVK>
AVK>Речь, как видишь, не о бинарном формате вообще, а о вполне конкетном BinaryFormatter
Речь в стартовом сообщении идёт о том, как десериализовать "старые данные". Я же отвечал на то, что "Бинарная сериализация — худший из возможных вариантов". Мой ответ к теме топика имеет тоже отношение, что и советы о том, как надо было правильно сериализовать — топикстартеру-то всё одно это не поможет
А вот в тему "чем порекомендуете пользоваться для хранения даных" мой ответ к месту — бинарная сериализация вполне нормальный инструмент, если им правильно пользоваться, так что смысл твоих возражений мне попросту не понятем. Не можешь всё-таки разъяснить их без недомолвок и намёков напрямую?
Help will always be given at Hogwarts to those who ask for it.
Re[2]: Проблема десериализации объекта
От:
Аноним
Дата:
16.03.10 08:30
Оценка:
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, BUTEK, Вы писали:
BUT>>В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU. BUT>>Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?
K>Плавали, знаем Для решения проблемы нужно сделать свою реализацию класса SerializationBinder и подсунуть её форматтеру с помощью свойства Binder. Вообще из-за этого гемора я недолюбливаю бинарную сериализацию...
Здравствуйте, _FRED_, Вы писали:
_FR>… Xml конечно удобно, но двоичный формат компактен — в каждом случае можно выбрать что либо самое подходящее, а вот система: некий заголовок с версией и, возможно, какой-то дополнительной метаинформацией, — штука полезная при любом формате.