OneStream XF基于ADO.Net实现API是否属于合理的通用数据序列化实践

首先可以明确：将ADO.Net作为公共API的通用数据序列化依赖，不属于现代API设计的最佳实践，主要原因有三点：

• 技术栈耦合极强：这类设计直接将API的调用方限制在.Net生态内，非.Net技术栈（Java、Python、前端等）几乎无法正常解析ADO.Net特有的XML序列化结果；就算是.Net生态内，不同版本框架的ADO.Net序列化格式也存在兼容性风险，这也是.Net Core早期版本迟迟没有移植ADO.Net相关组件的核心原因之一。
• 传输解析效率极低：ADO.Net的序列化结果会携带大量冗余的schema定义、关系元数据，同等业务数据量下，序列化后的体积通常是普通POCO XML序列化结果的2_{3倍，是JSON序列化结果的4}5倍，会额外浪费大量传输和解析资源。
• 存在明确的安全风险：微软官方安全指南多次提示，不受信任的DataSet/DataTable反序列化存在远程代码执行的高危漏洞，公共API暴露这类类型等于直接将安全风险转嫁给所有调用方。

关于你提到的几个具体疑问，统一回复如下：

1. 目前没有官方编程规范明确一刀切禁止在新API中使用ADO.Net，但微软官方发布的《.Net现代Web API设计指南》、REST接口设计通用规范都明确要求API契约要和具体技术栈实现解耦，暴露ADO.Net类型本质违反了契约中立的设计原则，属于行业普遍不推荐的实现方式，这也是你很少看到新项目、新NuGet包基于ADO.Net构建的核心原因。
2. 是否要避免使用这类API，可以根据场景判断：如果是内部封闭系统，所有调用方都是受控的.Net环境，完全可以继续使用，毕竟ADO.Net的快速建模、自带数据关系校验的特性能显著提升内部开发效率；如果是跨团队、跨技术栈的公共集成场景，能避免使用就尽量避免。
3. 针对这类依赖ADO.Net的API，非常建议封装一层Facade防腐层：上游对接OneStream原生API拿到DataSet结果后，直接映射为你自己定义的POCO模型，对外只暴露通用的JSON或者精简XML格式接口，将ADO.Net的实现细节完全屏蔽在防腐层内部。后续就算OneStream接口调整、或者替换为其他财务系统，只需要修改防腐层的映射逻辑即可，上层业务代码不需要做任何改动，可以大幅降低长期维护成本。

内容的提问来源于stack exchange，提问作者David Beavon