我们正在处理使用它们的旧数据Feed和应用。我们想要引入Xml，但额外的性能开销很难证明。你是如何解决这个问题的？
我们正在使用许多预先存在的数据源，通常是每隔几分钟更新一次的知名目录中的文件。使这种遗留数据标准兼容的一种方法是将其转换为Xml并发布XSD - 使其可供所有人使用。但是，这意味着我们将在使用之前对所有内容进行序列化/反序列化，而目前应用程序只是读取数据。
我们来自
File -> App
到
File -> Serialize to XML -> ESB/Network -> Deserialize -> App
后者显然更加结构化和可重复使用，是一种“更好”的架构。但是我们要采取的性能影响很大。
答案 0 :(得分：1)
仅在您必须的位置转换为XML;不要为了“标准符合性”或“更好的架构”而进行转换。当然，您宁愿添加更多功能或以其他方式改进您的产品，对吧？这是反映YAGNI原则的好时机。
答案 1 :(得分：0)
您可能会考虑使用像JSON这样更“轻量级”的数据格式。它需要更少的解析工作，并且如果需要在某处出现XML，可以通过简单的XSLT转换为XML。
我们目前正在一个嵌入式设备项目中使用它，其中WWW只占很小的一部分，但我们非常满意。是的，JSON格式配置文件，双向JSON套接字，以及非常重要的JSON到静态Javascript，使动态Web应用程序能够控制它。
答案 2 :(得分：0)
为什么没有为这样的客户创建库？也许XML在“云”中是可以的，但在你自己的内部网上使用遗留格式我只会确保提供一个库 - 我的第一个直觉就是包装格式层和提供者层。似乎大多数格式层都已完成（毕竟你有使用数据的应用程序），如果（我承认一个很大的if）恢复/弹性约束不是太严格，包装文件流/套接字流很容易< / p>