Каков самый простой способ сериализации сложного слоя объекта в .NET для кэширования?

Question

Пытается ввести кэширование/состояние, сохраняющееся в среднем уровне приложения со сложным слоем объекта (и уровнем обслуживания WCF, а не фокусом здесь), работающим под IIS. Устроились на memcached/enyim в качестве архитектуры кэширования, и теперь вам нужно получить эти объекты, чтобы они эффективно сериализовались (скорость и пространство).

слоя объекта имеет много указателей и взаимозависимостей между объектами, вдоль этих линий:

internal class SomeObj 
{ 
    private string attr1; 
    private int attr2; 
    private OtherObj otherObj; 
    private List<OtherOtherObj> otherObjs; 
} 

internal class OtherObj 
{ 
    //...more attributes 
} 

internal class OtherOtherObj 
{ 
    // you get the idea 
} 

Обратите внимание, что все поля являются частными. Также стоит отметить, что большинство объектов являются внутренними, и многие свойства либо доступны только для чтения (без набора), либо используют набор с точки зрения пользователя (т. Е. Делают объект «грязным»), поэтому его нельзя использовать при регидратации. У меня есть десятки типов, которые требуют кэширования.

Мне нравится внешний вид как protobuf-net, так и msgpack, но мне нужно как можно быстрее выполнить сериализацию с минимальным изменением существующей архитектуры (которая работает хорошо, как есть), и это кажется так как оба они имеют ограниченную поддержку иерархии объектов. Я хорошо понимаю сериализацию типа DTO, но новичок в планировании правильного способа сериализации объекта для кеша. Может ли один из этих инструментов работать на меня? Я застрял с помощью встроенного .NET-бинарного файла, чтобы работать с конструктором, а также переписывать атрибуты и объекты на своих собственных условиях?

EDIT: просто уточнить, что последний вопрос - может иметь больше смысла, если читать «Могу ли я застрял с помощью встроенного в .NET бинарного , так что я могу контролировать конструктор, и заселить атрибуты и объекты на моей термины

Answer 1

Я не могу комментировать msgpack, но да:? Protobuf-сеть может сделать все, что вы упомянули, в том числе:

• сериализации непубличные типы
• сериализировать частные поля
• сериализация дерева
• конструктор-пропуск или предоставленного пользователь завод (или просто конструктор без параметров)
• сериализации полных/циклических графы (в явном виде маркировки пострадавших как ссылки)
• атрибута использования или конфигурацию во время выполнения без изменения DTO у всех (хотя говоря, атрибуты, как правило, легче)
• быстрый и компактный выход
• поддерживают наследование

В случае примера, приведенного, простейший «д oes it work "test будет просто создавать типы с помощью [ProtoContract] (в этом атрибуте для пропуска конструктора есть необязательная настройка) и пометить поля как [ProtoMember (n)], например n = 1,2, 3, ... (уникально в каждом типе, но не обязательно должны быть уникальными между типами)

Кроме того, что мы используем Redis + BookSleeve, а не memcached + enyim, это именно то, что мы делаем в Stack Exchange для кэширования объектов. Ну, мы также делаем спекулятивный gzip для больших объектов - если есть много строковых данных, gzip может помочь сбрить несколько лишних байтов.