After reading Rocky's blog about DataSets and Web Services, I am afraid that he is falling into the same trap that other's have (including the emminently qualified Tim Ewald) with respect to DataSets. DataSets work well in Web Services but not by default. As I mentioned in:
The reason I like DataSets across Web Services so much is simple. On my side of the interop wall, I can treat them like a set of data-centric objects. But when I expose them via Web Services, I can treat the entire DataSet as a document. I like doc-literal web services. The magic here lies in the fact that the schema of the DataSet can be simply described with XSD. In fact, for non-typed DataSets that can be described inline with WriteXmlSchema() (so it can be interpreted on the other side of the interop wall).
For typed DataSets it gets even better. An XSD is the source of Typed DataSets, so exposing your XSD to describe your 'document' is a natural way of doing things. In fact, if you're not using ?wsdl for your .NET web services (which you shouldn't!), you can refer to the .xsd to describe the types that your web service expose.
I am passionate about this because creating web services to banty around your business objects is fine, but seems wholly unnecessary. I hope I can get Rocky to see the light.
I love Sahil's discussion of this too:
|Vue.js by Example (New Lower Price)|
|Bootstrap 4 by Example (New Lower Price)|
|Intro to Font Awesome 5 (Free Course)|
|Building an API with ASP.NET Core (New Course)|
|Building a Web App with ASP.NET Core, MVC6, EF Core, Bootstrap and Angular (updated for 2.2)|
|Less: Getting Started (New)|
|Using Visual Studio Code for ASP.NET Core Projects|
|Implementing ASP.NET Web API|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||v4.0.30319||Runtime Framework||x86|
|App Path||D:\home\site\wwwroot\||Runtime Version||.NET Core 4.6.27514.02|
|Operating System||Microsoft Windows 10.0.14393||Runtime Arch||X86|