设计模式 – 对象到xml转换的设计模式

我们有一组不同的POCO实体,它们代表应用程序的域模型.现在我们需要提出一个xml表示来编译来自不同实体的数据,这些数据将由其他一些应用程序使用.我们有一个关于最终表示应该如何的参考xml.

基于以上所述,我有两个主要针对最佳实践和优化的问题：

>给定目标xml结构,基于来自不同实体的数据创建xml文件的最佳和推荐方法是什么？我应该尝试使用xsl变换或基于xsd生成目标类并使用自定义翻译等.
>由于这是POC练习的一部分,因此XML转换最终将替换为数据库中的数据持久性或/和转换为JSON对象.我想知道我是否可以使用一些设计模式来抽象出目标实现,这样当xml生成例程被DAL调用或JSON转换代码替换时,主代码就不会受到影响.有任何想法吗？

使用 MS xsd tool基于目标xsd创建目标模型(POCO-ish),并通过隐藏翻译实现的外观进行代码转换.

为简化转换,您可以使用例如Automapper on github.

从目标模型中可以很容易地使用例如Entity Framework生成XML,JSON或持久化数据.

genric JSON序列化的示例：

public static string GetString<T>(T value)
    {
        using (var ms = new MemoryStream())
        {
            var ser = new DataContractJsonSerializer(typeof(T));
            ser.WriteObject(ms, value);
            byte[] json = ms.ToArray();
            ms.Close();
            return Encoding.UTF8.GetString(json, 0, json.Length);
        }
    }

我过去曾尝试过XSLT路线,虽然功能强大,但它有快速复杂的趋势.使用上面的目标模型,您可以根据需要调试转换,它还为您提供了一系列前进的机会.

Re：AutoMapper,在这种情况下,当目标结构很复杂并且可能与源不同时,很难让AutoMapper直接映射所有内容,我通常创建一个Orchestrator / SuperMapper,负责内部使用AutoMapper的整体结构/映射.

提示：如果目标需要多个值,则可以将其设置为映射到同一对象的序列,请参阅此question/answer.

没有特定的结构,很难给出一个很好的通用答案.

Re：Facade Wikipedia对这种模式有一个很好的定义>> Facade on Wikipedia但简而言之,为Orchestrator / SupperMapper定义最简单的接口,以便将结构与应用程序其余部分的内部工作分开.这样,当您的需求发生变化时,您可以轻松地将其换成其他东西.这样,您的应用程序的其余部分无需了解AutoMapper或目标模型.所有它知道的是放入源模型并期望让Json回来.