Ограничение дерева наследования protobuf-net

Продолжаю свои поиски подчинить protobuf-net своей воле..

Я видел несколько вопросов о SO о том, как динамически добавлять подклассы, чтобы сериализатор мог кодировать подкласс..., например это или это

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

Причина, по которой мне это нужно, заключается в том, что позже, когда я десериализую данные, код подкласса будет даже недоступен, поэтому создание подкласса будет даже невозможно.

Есть ли способ ограничить/запретить сериализацию подклассов?

В моем случае у меня есть список, в котором некоторые элементы списка являются производными классами.

Я хотел бы найти способ заставить protobuf-net сериализовать все как BaseClass, а также десериализовать в BaseClass...

Я пытался заглянуть в код, но не нашел ничего слишком полезного.


.net inheritance c# protocol-buffers protobuf-net
person damageboy    schedule 03.10.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Обычно библиотека очень тщательно выявляет производные классы и обращается с ними иначе, чем с базовым классом. Единственным текущим исключением являются прокси-классы, в частности Entity Framework и NHibernate. Для аккуратного решения было бы целесообразно добавить какой-нибудь переключатель "игнорировать подклассы". Но пока этого не существует, очень ленивый (и хакерский) подход будет состоять в том, чтобы обмануть существующую обработку для NHibernate, например:

namespace NHibernate.Proxy {
    interface INHibernateProxy {}
}
...
public class SomeDerivedType : BaseType, INHibernateProxy {}

затем это будет автоматически сериализовано в соответствии с BaseType. Однако в этом есть слабый запах измены.

person Marc Gravell    schedule 04.10.2011
comment
Слабый запах, говоришь? ;) Думаю взломать исходник Коу но спасибо за предложение - person damageboy; 04.10.2011
comment
@damageboy, если вы хотите добавить для этого какой-то собственный механизм, TypeModel.ResolveProxies стоит посмотреть. Я не против добавления здесь API, специфичного для protobuf-net. - person Marc Gravell; 04.10.2011
comment
Просто так мы здесь в чистоте ... Причина, по которой вы указываете мне на ResolveProxies, заключается в том, что она вызывается из ThrowUnexpectedSubtype в качестве последнего средства перед генерацией исключения? - person damageboy; 04.10.2011
comment
@damageboy есть, IIRC, количество мест (не только ThrowUnexpectedSubtype), которые используют этот метод в качестве второго шанса - самое главное TypeModel.GetKey (именно так он выбирает стратегию из Type) и FindOrAddAuto / FindWithoutAdd. - person Marc Gravell; 04.10.2011
comment
Привет, Марк, я закончил тем, что добавил свойство в MetaType: FlattenUnexpectedSubtypes, которое в конечном итоге изменяет испускаемый генератором кода IL в соответствии с наличием этого флага... Кажется, работает нормально... Я пытался отправить вам патч пару раз дней назад для какой-то другой функции, но не получил от вас никакого ответа ... если электронная почта является предпочтительным способом связи для исправлений? - person damageboy; 04.10.2011
comment
@damageboy не хотел обидеть; мой почтовый ящик - дикое и опасное место... я проверю позже - person Marc Gravell; 04.10.2011
comment
@MarcGravell Это когда-нибудь исправляли? Мне нужен этот функционал. - person David Pfeffer; 31.01.2012
comment
@MarcGravell Это когда-нибудь попадало куда-нибудь? Или есть новый способ сделать это в v2? - person Jeremy Seekamp; 25.04.2013