Хорошо, сериализация - это аспект к классам, который обычно рассматривается как ортогональный, то есть классы должны почти ничего о нем не знать. «Почти», потому что у вас есть случаи, когда объекты не должны быть сериализованы (например, прокси) или есть члены, которые не должны быть сериализованы.
Для этого были созданы атрибуты сериализации - даже в классе Type
есть свойство IsSerializable
. Таким образом, ваш подход уже очень хорош в том смысле, что объектам не нужно ничего делать для сериализации, кроме использования атрибутов. Плохо то, что вы ловите ошибки только во время выполнения, а не во время компиляции. Вы можете установить некоторые меры безопасности, такие как интерфейс маркера ISerializable
, и добавить ограничение типа в свой класс IO
, но это может быть невозможно (сторонние библиотеки) или много усилий (изменение всех классов вокруг). Вы могли бы даже пойти так далеко, чтобы переложить сериализацию на объекты, чтобы они точно знали, как де-сериализовать, но я сомневаюсь, что это стоит усилий, тогда как вы сможете уловить большинство проблем во время выполнения с юнит-тестами.
Единственная реальная проблема, которую я вижу, состоит в том, что вы можете десериализовать объект типа B
, когда вы фактически пытаетесь десериализовать тип A
. Теперь я бы сказал, что нет никакой разницы в том, что ваш сериализатор генерирует недопустимое исключение приведения или знает, что вы десериализовали неправильный тип, прежде чем закончите - в обоих случаях у вас есть проблема, и ваше приложение не может делать то, что должно.
Вы можете обойти проблемы с версией BinaryFormatter
с помощью пользовательского связывателя сериализации или вы можете рассмотреть возможность использования сериализатора xml.