Здравствуйте, grosborn, Вы писали:

G>Прочитай свои же посты и найдешь упоминанием о тайном знании.

Ты не виляй, ты ответь на вопрос.

G>>> Как это еще называется?
AVK>>Ну уж никак не враньем.
G>Вообще-то тут может быть три варианта, вранье, глупость и заблуждение. Выбирай.

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

G>>>>> У него только один способ использования, его нельзя неправильно применить.
AVK>>>>Какой такой один способ?
G>>>Метод Serialize() он такой, опций практически нет. Для тебя это новость?
AVK>>Это не способ использования.
G>О, это аргумент, да еще какой. Твой папа случайно не депутат, не?

О, уже на личности перешел. Ответь на простой вопрос — какой один способ использования ты упоминал.

AVK>>Нет, просто я BF применяю правильно.
G>О да, метод один, опций нет, но ты его применяешь правильно, а другие нет.

Именно. Потому что метод это не способ применения. Мне так кажется, что ты просто не понимаешь вопроса. Способ применения ака use case предполагает в том числе конкретную цель использования функционала. Так вот — твоя цель негодная. При чем тут единственность метода и отсутствие у него параметров?

AVK>>И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков.

G>До тебя не доходит что это и есть кривизна

Это до тебя не доходит, что у любого кода есть область применения.

G>>>Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
AVK>>Какие именно?
G>Все.

То есть ни одной конкретной ты указать не можешь. ЧТД.

G>>>исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов.
AVK>>Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать.
G>Опять бла-бла-бла, подтвердить свои слова ты не можешь.

А зачем их подтверждать, если ты сам на грабли уже наступил и прочувствовал неверность своих предположений на практике? Или, может, ты расскажешь, как следовало спроектировать ремоутинг, чтобы он обходился без сериализации приватных данных?

G>Биндер якобы не для того что бы биндить. Ага-ага, мы верим, ага.

Не надо верить. Надо открыть исходники бинарного remoting channel и посмотреть на тамошний биндер.

G>>> Откуда только он их берет, их нет в сериализуемых данных.
AVK>>Есть. Точнее были.
G>Не было там этих классов

Ну конечно, BF их сам придумал И Unity он тоже сам откуда то заимпортировал.

G>, там достаточно простая структура объектов и они там не нужны.

А ты просмотрел все приватные поля всего графа этих объектов?

AVK>>>>Это именно что правильное решение.
G>>>Это следствие кривизны чьих-то рук
AVK>>Конечно, того кто для долго живущих данных решил использовать BF.
G>И это работает

Это НЕ работает.

G>но только в других языках и в других библиотеках. И только в .НЕТ с их прямыми руками это не работает.

В дотнете тоже все работает. Надо просто подбирать правильный инструмент.

G> Ты случайно не в МС работаешь?

Нет.

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

AVK>И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков. Вот XmlSerializer или DataContractSerializer использовать можно, потому что формат сериализованных данных явным образом специфицируется. К сожалению, оба они текстовые, поэтому здесь и предложили использовать Protobuf-Net.

Ты забыл ещё JSON! Их тоже вроде 2-3 штуки!!! публичных должно быть, сам видел

Не находишь что именно то что ты написал как-бы намекает что топик-стартер прав? Всё ли правильно, если так много разных! сериализаций, и, внезапно, ты сам советуешь стороннюю для типовой задачи?

В .NET год за годом лепят сериализации по одной для каждого убогого случая, вместо одной сделанной с умом и с продуманной архитектурой. Нужно было разделить ответственность между классами и вместо захардкоженной несколько раз фигни на аттрибутах создать набор перечислителей полей или свойств отдельно, отделить форматтеры от перечислителей и реализовать самые основные вроде XML, Binary, JSON, SOAP, Protobuf и т.п., позволить передавать десериализатору биндер и фабрику для создания объектов или привязки их к существующим, отделить группу неких мапперов или migration helper'ов для разруливания проблем с версионностью. Короче подумать перед тем как делать. А то что сейчас налеплено — захардкодили поддержку "своих" аттрибутов и вытащили наружу пару методов для создания видимости возможности расширения, и так 5-6 раз, это несерьёзно.

G>>Так что все эти твои заявки верны с точностью до наоборот и просто смешны.

AVK>Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать. И биндер сделан вовсе не для того чтобы с версиями воевать, а для сериализации MBR объектов (через биндер Transparent Proxy зам еняется на ObjRef и обратно). То, что ты решил его использовать не по назначению — твоя личная проблема.

Это вы ещё в ракете не смотрели использовании ISerializationSurrogate не копались , тот же биндер вид сбоку.

Здравствуйте, hi_octane, Вы писали:

_>Ты забыл ещё JSON! Их тоже вроде 2-3 штуки!!! публичных должно быть, сам видел

Я не забыл. Во-первых в самом фреймворке их вроде нет (MVC вроде сейчас как то отдельно), во-вторых это текстовый формат.

_>Не находишь что именно то что ты написал как-бы намекает что топик-стартер прав?

В чем он прав? В том что BF использовал там где ненужно, или в том что считает что BF не должен сериализовать на основании приватной структуры?

_> Всё ли правильно, если так много разных! сериализаций, и, внезапно, ты сам советуешь стороннюю для типовой задачи?

Я нигде не советовал одну конкретную сериализацию.

_>В .NET год за годом лепят сериализации по одной для каждого убогого случая, вместо одной сделанной с умом и с продуманной архитектурой.

Потому что абсолютно универсальная сериализация не нужна. Но если ты так уверен в обратном — можешь начать проект своей, правильной. Если это будет нужно ощутимому количеству людей тебя поддержат.

_>Это вы ещё в ракете не смотрели использовании ISerializationSurrogate не копались , тот же биндер вид сбоку.

Копался. Я тебе больше скажу, в свое время фактически полностью пришлось переписать брата близнеца BF — SoapFormatter, так что я в теме, не переживай. Потроха ремоутинга там торчат отовсюду.

Здравствуйте, grosborn, Вы писали:

G>Ни одного аргумента от тебя не поступило, демагогия, намеки на единственно правильное использование, отрицание фактов и сравнений. Достойный лидер для этого ресурса.

Эмм... вообще-то BinaryFormatter действительно не подходит для долговременного хранения данных, особенно если планируется что схема данных или используемый фреймворк будет меняться.

В официальной документации ограничиваются полунамёками, например, вот тут:

To ensure proper versioning behavior, follow these rules when modifying a type from version to version:
* Never remove a serialized field.
* Never apply the NonSerializedAttribute attribute to a field if the attribute was not applied to the field in the previous version.
* Never change the name or the type of a serialized field.
...

Не, конечно можно потратить время на изучение и поддержку вот этого, но я предпочёл бы хранить данные в xml/лёгковесной СУБД.

Здравствуйте, Sinix, Вы писали:

S>Не, конечно можно потратить время на изучение и поддержку вот этого

Не стоит имхо — MSOSD это отмазка для суда, а не важный технический документ. На крайняк есть же бинарный формат в WCF, хоть и XML-подобной структуры, если уж так не хочется внешнюю библиотеку.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Sinix, Вы писали:

S>>Не, конечно можно потратить время на изучение и поддержку вот этого

AVK>Не стоит имхо — MSOSD это отмазка для суда, а не важный технический документ. На крайняк есть же бинарный формат в WCF, хоть и XML-подобной структуры, если уж так не хочется внешнюю библиотеку.
Интересно почему не сделать сразу бинарную сериализацию на уровне локальной БД. Где есть таблица типов. Поля с объектами состоят из двух полей таблица типа и номер строки в этой таблице.
Все валуе типы хранятся в бинарном виде а всякие строки и прочие блобы в таблицах типа блоб. Так мы получаем набор полей и можем сравнивать версии и по сути и иметь возможность преобразовывать из одной версии в другую или просто не заполнять отсутствующие поля. При этом объем такой БД будет небольшим. Лишние байты это незаполненные до конца страницы. Так это будет даже легче чем XML сериализация а по объему значительно меньше.

Здравствуйте, Serginio1, Вы писали:

S> Интересно почему не сделать сразу бинарную сериализацию на уровне локальной БД.

Почему не сделать? Для сериализации в БД есть целая пачка ORM от навороченных до очень легких и даже некоторое количество ООБД и NoSQL движков. Только такие сериализаторы очень сильно отличаются от сериализаторов в поток по очевидным причинам.

_>>Не находишь что именно то что ты написал как-бы намекает что топик-стартер прав?
AVK>В чем он прав? В том что BF использовал там где ненужно, или в том что считает что BF не должен сериализовать на основании приватной структуры?
В том что нормальной сериализации в общем нет, есть штук 6 каких-то других.

_>> Всё ли правильно, если так много разных! сериализаций, и, внезапно, ты сам советуешь стороннюю для типовой задачи?
AVK>Я нигде не советовал одну конкретную сериализацию.

Я считаю правильным использовать протокол с явным контрактом, например Protobuf.

тут

Автор: AndrewVK
Дата: 13.06.13

, наверное я неправильно истолковал, это был не совет совсем, а наборот, сорри.

_>>В .NET год за годом лепят сериализации по одной для каждого убогого случая, вместо одной сделанной с умом и с продуманной архитектурой.
AVK>Потому что абсолютно универсальная сериализация не нужна.
Несколько кривых нужнее. Понял. Больше в это болото со своим уставом лезть не буду

AVK>Но если ты так уверен в обратном — можешь начать проект своей, правильной. Если это будет нужно ощутимому количеству людей тебя поддержат.
Спасибо, как флеймер со стажем, я в сперва добейся не играю Но если вдруг сюда придёт кто-то из MS с вопросом как запилить сериализацию так чтоб в этот раз точно нормально получилось, думаю все прошаренные челы поотвечают и будет наконец щасте.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, grosborn, Вы писали:

G>> Или варианты озвученные ниже ты считаешь правильным использованием?

AVK>Я считаю правильным использовать протокол с явным контрактом, например Protobuf. А BinaryFormatter предназначен прежде всего для ремоутинга (особенно в части кроссдоменного взаимодействия), где расползание сборок с контрактами недопустимо по куче других причин или просто невозможно, поэтому он может смело полагаться на внутренние детали реализации. Если же кто то решил использовать его вместо стандартизованных бинарных форматов или БД, то он ССЗБ, а не программисты в МС виноваты.

Я как-то ни разу не фанат RSDN-админов (а то и наоборот), но вот с выделенным соглашусь на все 100 промилле. Бинарный форматер — как карман в штанах, всё входит и выходит. Но вот надел другие штаны — там карман уже не обязан быть таким же, как в предыдущих (хотя может и повезти, но надеяться не надо).

Здравствуйте, hi_octane, Вы писали:

_>В том что нормальной сериализации в общем нет

Начать следует с определения нормальной сериализации. Лично у меня есть большие сомнения в том, что нужна сверхуниверсальная, потому что требования в разных юзкейсах отличаются очень сильно.

AVK>>Я нигде не советовал одну конкретную сериализацию.
_>

Я считаю правильным использовать протокол с явным контрактом, например Protobuf.

Значения слова "например" понятно?

AVK>>Потому что абсолютно универсальная сериализация не нужна.
_>Несколько кривых нужнее

Осталось доказать, что все сериализации в фреймворке кривые.

AVK>>Но если ты так уверен в обратном — можешь начать проект своей, правильной. Если это будет нужно ощутимому количеству людей тебя поддержат.
_>Спасибо, как флеймер со стажем, я в сперва добейся не играю

Это не сперва добейся, это вполне жизненный совет.

_> Но если вдруг сюда придёт кто-то из MS с вопросом как запилить сериализацию так чтоб в этот раз точно нормально получилось, думаю все прошаренные челы поотвечают и будет наконец щасте.

Думай.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>> Интересно почему не сделать сразу бинарную сериализацию на уровне локальной БД.

AVK>Почему не сделать? Для сериализации в БД есть целая пачка ORM от навороченных до очень легких и даже некоторое количество ООБД и NoSQL движков. Только такие сериализаторы очень сильно отличаются от сериализаторов в поток по очевидным причинам.

А Бд это и есть поток, только не последовательный. Просто бОльшая абстракция. Просто в Net нельзя использовать адрес в памяти а так просто построить индекс.
Или придется для каждого тип создавать Хэш таблицу и ключем будет количество Записей В ХашТаблице. Перед записью проверяем есть ли такой объект в Хэш таблице если есть заносим в Хэш таблицу и записываем дальше этот объект и возвращаем ключ, если уже есть просто возвращаем ключ. Такая же операция и при десериализации. Просто вместо Хэш таблиц будут массивы (размер таблиц нам известны. И там не нужно навороченные бд. Ключ это номер записи а списки можно хранить ввиде однонаправленных списков. Для null использовать 0 или -1.

Здравствуйте, Serginio1, Вы писали:

S> А Бд это и есть поток, только не последовательный.

Нет, БД это не поток, потому что рандомный доступ без перемещения курсора, и потому что индексный поиск как минимум.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>> А Бд это и есть поток, только не последовательный.

AVK>Нет, БД это не поток, потому что рандомный доступ без перемещения курсора, и потому что индексный поиск как минимум.
Ну номер записи это не совсем поиск (хотя внутри нужно найти страницу). Если записи будут иметь поля только валуе типов то и ссылок не будет.
Но почему наряду с существующими типами сериализации не сделать сериализацию в БД? При чем она будет еще и компактнее бинарной сериализации так как поле для типа может иметь тип int (номер таблицы в БД).
Описание полей каждой таблицы тоже зашиты в определенные таблицы БД. По сути это более универсальное решение, чем существующие.

Здравствуйте, Serginio1, Вы писали:

S>Ну номер записи это не совсем поиск (хотя внутри нужно найти страницу). Если записи будут иметь поля только валуе типов то и ссылок не будет.

Если бы у бабушки был ...

S>Но почему наряду с существующими типами сериализации не сделать сериализацию в БД?

Потому что она уже есть, называется ORM. Если же писать в БД как в файл, всегда одним куском весь граф, то тогда и БД не нужна.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>>Ну номер записи это не совсем поиск (хотя внутри нужно найти страницу). Если записи будут иметь поля только валуе типов то и ссылок не будет.

AVK>Если бы у бабушки был ...

S>>Но почему наряду с существующими типами сериализации не сделать сериализацию в БД?

AVK>Потому что она уже есть, называется ORM. Если же писать в БД как в файл, всегда одним куском весь граф, то тогда и БД не нужна.
ORM это не то. Например тип объекта могут быть потомки а может и просто поле типа Object. И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию. Второе сама БД может быть максимально облегченной и не меняться со временем и храниться в Одном файле в какой нибудь System.Runtime. При этом скорость сериализации десериализации будет достаточно высока и универсальна

Здравствуйте, Serginio1, Вы писали:

S> ORM это не то.

И в чем отличие? Что ORM не позволяет тебе сделать?

S> Например тип объекта могут быть потомки а может и просто поле типа Object.

И что?

S> И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию.

А ORM, по твоему, как работает?

S> Второе сама БД может быть максимально облегченной

ORM этому не препятствуют. А есть специальные ООБД, в которых ORM встроен.

S>При этом скорость сериализации десериализации будет достаточно высока и универсальна

Угу, берешь linq2db, и по скорости сериализации BF остается в глубокой попе.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>> ORM это не то.

AVK>И в чем отличие? Что ORM не позволяет тебе сделать?
Ну тем, что это простейшее отображение, где не нужно ни каких транзакций, никаких блокировок (при условии записи в одном потоке).
S>> Например тип объекта могут быть потомки а может и просто поле типа Object.

AVK>И что?

S>> И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию.

AVK>А ORM, по твоему, как работает?
Особо не вникал в суть, но например проблема в 1С где поле может быть ссылкой на объекты из разных таблиц вроде как не совсем решена в реляционных БД.
Хотя могу ошибаться. Там поле должно иметь структуру таблица, индекс

S>> Второе сама БД может быть максимально облегченной

AVK>ORM этому не препятствуют. А есть специальные ООБД, в которых ORM встроен.
Ну так нужно взять одну такую БД и движок зашить в общую сборку. Так как не нужны индексы, транзакции и блокировки, база там максимально облегченная.

S>>При этом скорость сериализации десериализации будет достаточно высока и универсальна

AVK>Угу, берешь linq2db, и по скорости сериализации BF остается в глубокой попе.

Здравствуйте, Serginio1, Вы писали:

AVK>>И в чем отличие? Что ORM не позволяет тебе сделать?
S> Ну тем, что это простейшее отображение, где не нужно ни каких транзакций, никаких блокировок (при условии записи в одном потоке).

Транзакции и блокировки вовсе не обязательный признак ОРМ. Ты путаешь ОРМ и РСУБД.

S>>> И зачем ORM если у нас все есть в метаданных мы можем создать БД по описанию.
AVK>>А ORM, по твоему, как работает?
S> Особо не вникал в суть

Так вникни.

S>, но например проблема в 1С

В твоем мире ничего кроме 1С не существует?

AVK>>ORM этому не препятствуют. А есть специальные ООБД, в которых ORM встроен.
S> Ну так нужно взять одну такую БД и движок зашить в общую сборку.

Так и такое есть.

Здравствуйте, AndrewVK, Вы писали:

S>> Ну так нужно взять одну такую БД и движок зашить в общую сборку.

AVK>Так и такое есть.
Почему тогда такой сериализации нет вместе с XML и Бинарной? Там ничего сложного нет.