Почему классу XML-Serializable нужен конструктор без параметров

Я пишу код для сериализации Xml. С функцией ниже.

public static string SerializeToXml(object obj)
{
    XmlSerializer serializer = new XmlSerializer(obj.GetType());
    using (StringWriter writer = new StringWriter())
    {
        serializer.Serialize(writer, obj);
        return writer.ToString();
    }
}

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

Необработанное исключение: System.InvalidOperationException: CSharpConsole.Foo не может быть сериализовано, поскольку у него нет конструктора без параметров. в System.Xml.Serialization.TypeDesc.CheckSupported () в System.Xml.Serialization.TypeScope.GetTypeDesc (Тип тип, MemberInfo sourc e, логический directReference, Boolean throwOnError) в System.Xml.Serialization.ModelS TypeMetTepeTetGet Прямая логическая ссылка) в System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping (Тип тип, корень XmlRootAttribute, String defaultNamespace) в System.Xml.Serialization.XmlSerializer..ctor (Тип тип, пространство String defaultName) в System.Xml.Serialization. XmlSerializer..ctor (Тип тип)

Почему должен существовать конструктор без параметров, чтобы обеспечить успешную сериализацию xml?

РЕДАКТИРОВАТЬ: спасибо за ответ cfeduke. Конструктор без параметров может быть закрытым или внутренним.

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

Вы можете сделать свой конструктор privateили, internalесли хотите, просто пока он без параметров.

Это ограничение XmlSerializer. Обратите внимание, что BinaryFormatterи DataContractSerializer не требуют этого - они могут создать неинициализированный объект из эфира и инициализировать его во время десериализации.

Поскольку вы используете xml, вы можете подумать об использовании DataContractSerializerи пометке вашего класса [DataContract]/ [DataMember], но обратите внимание, что это меняет схему (например, нет эквивалента [XmlAttribute]- все становится элементами).

Обновление: если вы действительно хотите знать, BinaryFormatterи т.д. используйте FormatterServices.GetUninitializedObject()для создания объекта, не вызывая конструктор. Вероятно, опасно; Я не рекомендую использовать его слишком часто ;-p См. Также замечания по MSDN:

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

У меня есть собственный движок сериализации, но я не собираюсь его использовать FormatterServices; Мне очень нравится знать, что конструктор ( любой конструктор) действительно выполняется.

Ответ таков: без всякой веской причины.

Вопреки своему названию, XmlSerializerкласс используется не только для сериализации, но и для десериализации. Он выполняет определенные проверки вашего класса, чтобы убедиться, что он будет работать, и некоторые из этих проверок имеют отношение только к десериализации, но в любом случае он выполняет их все, потому что он не знает, что вы собираетесь делать позже.

Проверка того, что ваш класс не прошел, является одной из проверок, которые имеют отношение только к десериализации. Вот что происходит:

• Во время десериализации XmlSerializerкласс должен будет создавать экземпляры вашего типа.

• Чтобы создать экземпляр типа, необходимо вызвать конструктор этого типа.

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

• Таким образом, если объявленный вами конструктор принимает параметры, то единственный способ создать экземпляр вашего класса - вызвать тот конструктор, который принимает параметры.

• Однако XmlSerializerон не способен вызывать любой конструктор, кроме конструктора без параметров, поскольку он не знает, какие параметры передавать конструкторам, которые принимают параметры. Таким образом, он проверяет, есть ли в вашем классе конструктор без параметров, и, поскольку он этого не делает, происходит сбой.

Итак, если бы XmlSerializerкласс был написан таким образом, чтобы выполнять только проверки, относящиеся к сериализации, то ваш класс прошел бы, потому что в сериализации нет абсолютно ничего, что требовало бы иметь конструктор без параметров.

Как уже отмечали другие, быстрое решение вашей проблемы - просто добавить конструктор без параметров. К сожалению, это также грязное решение, потому что это означает, что вы не можете readonlyинициализировать какие-либо члены из параметров конструктора.

В дополнение ко всему этому, XmlSerializerкласс мог бы быть написан таким образом, чтобы позволить даже десериализацию классов без конструкторов без параметров. Все, что нужно, это использовать «Шаблон проектирования фабричных методов» (Википедия) . Судя по всему, Microsoft решила, что этот шаблон проектирования слишком сложен для программистов DotNet, которых, очевидно, не следует путать с такими вещами. Таким образом, по мнению Microsoft, программистам DotNet лучше придерживаться конструкторов без параметров.

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

Я думаю, что есть обходной путь, чтобы сделать конструктор приватным.