Стратегии сериализации объекта для целей аудита / ведения журнала в .NET?

Question

Допустим, у меня есть приложение, которое обрабатывает сообщения. В данном случае сообщения - это просто объекты, которые реализуют интерфейс IMessage , который является просто маркером.

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

В идеале, я хочу, чтобы сообщение было сериализовано в формат, понятный человеку. Первым кандидатом является XML, хотя есть и другие, такие как JSON. Если бы я должен был сериализовать сообщения как XML, я хотел бы знать, является ли объект сообщения XML-сериализуемым. Один из способов - отразить тип и посмотреть, имеет ли он конструктор без параметров, а другой - потребовать интерфейс IXmlSerializable . Я не слишком доволен ни одним из этих подходов. Существует третий вариант, который заключается в том, чтобы попытаться сериализовать его и перехватить исключения. Это на самом деле не помогает - я хочу каким-то образом оговорить, что IMessage (или производный тип) должен быть xml-сериализуемым.

Маршрут отражения имеет очевидные недостатки, такие как безопасность, производительность и т. Д. IXmlSerializable Маршрут блокирует мои сообщения в одном формате, когда в будущем я, возможно, захочу изменить формат сериализации на JSON. Другое дело, что даже самые простые объекты теперь должны реализовывать методы ReadXml и WriteXml .

Существует ли маршрут с наименьшим объемом работы, который позволяет мне сериализовать произвольный объект (при условии, что он реализует интерфейс маркера) в XML, но не блокировать будущие сообщения в XML?

Answer 1

Таким образом, требование заключается в сериализации произвольного объекта (при условии, что он реализует интерфейс маркера) в удобочитаемом формате (возможно XML) самым простым способом.

Как упомянуто в Является ли он сериализуемым? Трудно определить, сериализуем ли объект.

Я могу придумать только 2 способа удовлетворить требования:

1. Добавление метода Serialize в интерфейс IMessage и принудительные классы реализовать собственный читабельный формат.
2. Интерфейс вашего приложения должен быть представлен как сервис, который принимает удобочитаемый формат. например служба WCF, которая принимает удобочитаемое сообщение (XML), которое вы можете регистрировать.

Вариант 1 может быть полезен для одитинга, но не настолько для повторной обработки. Также есть некоторые крайние случаи, которые могут вызвать проблемы.

Если это существующее приложение, то это, вероятно, нежизнеспособные варианты. Если это так, то, возможно, посмотрите на что-то вроде Json.NET , чтобы попытаться сериализоваться с максимальной отдачей.

Answer 2

Вы можете реализовать MessageBase, из которой получаются все ваши объекты сообщений, который содержит конструктор без параметров.Затем используйте MessageBase вместо IMessage.

Любопытно, если вы разрабатываете сообщения и хотите, чтобы все они были сериализуемыми, зачем вам проверять?

ВотРасширение универсального объекта, которое я использую много:

/// <summary>        
/// Converts an object to a serialized xml string       
/// </summary>
/// <param name="o">The <see cref="object"/> to serialize</param>
/// <returns></returns>
public static string ToXml(this object o)
{
    XmlSerializer xmlSerializer = new XmlSerializer(o.GetType());

    using (MemoryStream memoryStream = new MemoryStream())
    {
        using (StreamWriter streamWriter = new StreamWriter(memoryStream))
        {
            xmlSerializer.Serialize(streamWriter, o);
            streamWriter.Flush();
            memoryStream.Flush();
            memoryStream.Position = 0;

            using (StreamReader streamReader = new StreamReader(memoryStream))
            {
                return streamReader.ReadToEnd();
            }
        }
    }
}

Реализуйте его на своей базе сообщений, и вы - золотой.Не привязываться ни к чему.