I haven't seen many questions about OneStream XF (Extensible Finance) in stackoverflow. This may be the only one so far. I suppose it had to start somewhere.
I've started using their API's for integration. It was curious to me that they build their reporting API on top of ADO.Net. Both the "client API" and the "REST API" seem to rely heavily on XML serialization of ADO.Net.
I'm wondering if it is good practice to place a dependency on ADO.Net for general-purpose data serialization as OneStream has done. For me it feels very familiar, but I've got many old (bad?) habits as an enterprise C# developer. Generally I don't see many new projects or nuget packages that build on top of ADO.Net. In fact this part of the .Net Framework was excluded from .Net core for the longest time, and I think it was only added begrudgingly.
Don't get me wrong, I frequently use ADO.Net for my own (internal) purposes since it is easy to use the xsd designer interface to do ER modeling. And the DataSet class will validate some data, as well as relationships.
But as much as I like ADO.Net, I would NOT expose it in public API interfaces. I would probably use POCO's or, for text serialization, I would use a more simplified XML schema. I might even use JSON if web developers were likely to be involved...
Are there any programming guidelines that would exclude ADO.Net from modern, greenfield API's? Should developers avoid an API that relies on ADO.Net? Should we build a facade over these non-compliant API's, and prevent ADO.Net from leaking out into the rest of our integration layers? Any suggestions would be appreciated.