Проблема с дизайном класса сериализации .NET

У нас есть довольно большой граф объектов, который нужно сериализовать и десериализовать множеством разных способов (режимов). В некоторых режимах мы хотим, чтобы определенные свойства были десериализованы, а в некоторых - нет. В будущих режимах также возможно, что для свойств будет больше вариантов, чем «да» или «нет». Проблема теперь в том, как мы реализуем эти режимы.

Подход A (используйте конструктор десериализации и ISerializable.GetObjectData):

Если мы позволим каждому объекту графа сериализоваться с помощью конструктора десериализации, мы получим множество переключателей для всех различных режимов десериализации. Однако преимущество этого подхода заключается в том, что вся логика десериализации находится в одном месте, и если мы добавляем новые свойства, нам просто нужно изменить ISerializable.GetObjectData и конструктор десериализации. Еще одно преимущество состоит в том, что объект может учитывать внутренние состояния, которые могут быть открыты публично. Самым важным недостатком является то, что объекту данных необходимо знать обо всех возможных режимах сериализации. Если нам нужен новый режим, нам нужно изменить объекты данных.

Подход B (классы / методы фабрики десериализации):

Другой подход - иметь какие-то классы / методы фабрики десериализации по одному для каждого режима, который выполняет сериализацию и десериализацию извне (например, GraphSerializer.SerializeObjectTypeX (ObjectTypeX objectToSerialze). Преимущество здесь в том, что всякий раз, когда нам нужен новый режим, мы просто добавляем новый Factory Class / Method и наш Dataobject не загромождены всеми представленными режимами сериализации.Основной недостаток здесь заключается в том, что мне пришлось бы писать один и тот же код сериализации снова и снова для всех разных режимов. Если два режима отличаются только в одно или два свойства, но мне придется снова реализовать полную логику для всего графа.Когда я добавляю новое свойство к объекту данных, мне нужно обновить все фабричные классы.

Так что мне интересно, есть ли лучший подход к этой общей проблеме ИМХО. Или даже лучшая практика в .NET? Или, может быть, я просто подхожу ко всему с неправильной точки зрения?