Здравствуйте, varenikAA, Вы писали:
M>>Если я правильно помню, то один xsd может быть наследником второго. Но в подробности надо вникать. AA>Интересно, не смог найти к сожалению руководства.
Ройся тут https://www.w3.org/TR/xmlschema11-1/
В пункте 3.3.2.5 есть пример c extension. Где-то он должен быть описан. Это штатная вещь и C# ее поддерживает.
Есть две версии xsd очень похожей структуры.
Классы сгенерил в разные пространства имен.
Логика абсолютно одинакова, по крайней мере пока.
Но так как типы конкретные при десериализации не могу повторно заюзать логику.
Нельзя ли избежать дублирования по принципу DRY?
Понятно, что формально типы разные, но всё же.
Здравствуйте, varenikAA, Вы писали:
AA>Но так как типы конкретные при десериализации не могу повторно заюзать логику. AA>Нельзя ли избежать дублирования по принципу DRY?
Если я правильно помню, то один xsd может быть наследником второго. Но в подробности надо вникать.
Выделить общую часть (необходимую для generic-обработки) в интерфейс, сгенерить классы как partial, добавить partial файлы с определением интерфейса для каждого из типов.
Ещё вариант — генерить и сам код обработки.
Например в виде extensions к типам. Тогда общая часть логики обработки будет в генераторе (без дублирования).
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, varenikAA, Вы писали:
AA>>Но так как типы конкретные при десериализации не могу повторно заюзать логику. AA>>Нельзя ли избежать дублирования по принципу DRY? M>Если я правильно помню, то один xsd может быть наследником второго. Но в подробности надо вникать.
Интересно, не смог найти к сожалению руководства.
Здравствуйте, RushDevion, Вы писали:
RD>Выделить общую часть (необходимую для generic-обработки) в интерфейс, сгенерить классы как partial, добавить partial файлы с определением интерфейса для каждого из типов.
RD>Ещё вариант — генерить и сам код обработки. RD>Например в виде extensions к типам. Тогда общая часть логики обработки будет в генераторе (без дублирования).
C# не особо дружит с макросами, хоть в коре и появилась , но боюсь я такой путь не осилю. не хочется нарушать принцип KISS.
Есть подозрение, что в новой версии лишь добавлены плюсом новые типы документов, но для проверки все равно нужно что-то писать.
Здравствуйте, varenikAA, Вы писали:
AA>Есть две версии xsd очень похожей структуры. AA>Классы сгенерил в разные пространства имен. AA>Логика абсолютно одинакова, по крайней мере пока. AA>Но так как типы конкретные при десериализации не могу повторно заюзать логику. AA>Нельзя ли избежать дублирования по принципу DRY? AA>Понятно, что формально типы разные, но всё же.
Здравствуйте, varenikAA, Вы писали:
AA>Есть две версии xsd очень похожей структуры. AA>Классы сгенерил в разные пространства имен. AA>Логика абсолютно одинакова, по крайней мере пока. AA>Но так как типы конкретные при десериализации не могу повторно заюзать логику. AA>Нельзя ли избежать дублирования по принципу DRY? AA>Понятно, что формально типы разные, но всё же.
Вообщем, извратился, т.к. новая версия(2.3) расширяет старую(2.2), сделал так:
public static class XmlExt
{
public static void DeleteNamespaces(this XElement el)
{
el.Attributes().Where(a => a.IsNamespaceDeclaration).Remove();
el.Name = el.Name.LocalName;
if (!el.HasElements)
return;
foreach (XElement d in el.Elements())
DeleteNamespaces(d);
}
}
....
private static void PrepareDocument(string path, MemoryStream stream)
{
XNamespace ns = "http://types/2.3";
var doc = XDocument.Load(path);
doc.Root.DeleteNamespaces();
var sb = new StringBuilder();
var writer = XmlWriter.Create(sb);
doc.Save(writer);
writer.Flush();
var xdoc = new XmlDocument();
xdoc.LoadXml(sb.ToString());
xdoc.DocumentElement.SetAttribute("xmlns", ns.NamespaceName);
xdoc.Save(stream);
stream.Flush();
stream.Position = 0;
}
....