Чому для XML-серіалізаційного класу потрібен конструктор без параметрів

Я пишу код для серіалізації 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, Булева директна референція, Boolean castOnError) на System.Xml.Serialization.ModelScope.GetTypeModel (Тип Булева пряма довідка) на System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping (Тип типу, XmlRootAttribute root, String defaultNamespace) у System.Xml.Serialization.XmlSerializer..ctor (Тип типу, Простір String defaultName) на System.Xml.Serialization. XmlSerializer..ctor (тип типу)

Чому повинен бути конструктор без параметрів, щоб дозволити серіалізацію xml для успіху?

EDIT: дякую за відповідь 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, яких, мабуть, не слід непотрібно плутати з такими речами. Отже, програмістам DotNet слід краще дотримуватися конструкторів без параметрів, на думку Microsoft.

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

Я думаю, що існує рішення, щоб зробити конструктор приватним.