Any C# devs wanna explain the XML thing? To me having a separate class to deserialize each kind of XML document to its respective object seems nice and the "right" way to use XML. The class just becomes the config file. Generic loaders but poking at the tree is super brittle. Does C# come with magic to do this better?
Because if you have to invent the config file then isn't that creating a DSL and we're back to over engineering?
Active C# dev here, but I haven’t read the article.
For configuration these days XML is generally not used, they have a configuration system which can use a variety of underlying sources (like environment variables and JSON files) and you can either access these settings by key from a dictionary or trivially hydrate a plain old C# classes, including with collections.
People may still manually read their own configuration independent of this system or perhaps they’re just generally deserialising XML.
There are (I think) at least a few ways to work with XML in .NET.
For well known schemas I definitely generally recommend the C# class approach where you somewhat simply deserialize a file into well typed C# classes.
From your question it sounds like the XML API which allows you to arbitrarily query or manipulate XML directly was used here. I have on occasion used this when I don’t have the full schema for the XML available and need to tweak a single element or search for something with XQuery. It’s a useful tool for some scenarios, but a poor choice for others.
System.Xml has been around for a very long time. I use it in one of my tools as a MSN deserialization class to make all my old MSN history "readable" by traversing the nodes and picking out sending/receiving user, timestamp, and message.
> To me having a separate class to deserialize each kind of XML document to its respective object
You mean a separate function? Or a separated method in some class? (Given that C# can't do top level functions...)
Or else, you may want a type parametrized function that uses reflection to populate an object of any class you want. That would depend on how many different kinds of file you have, but the C# standard library has this function so you just use it.
I stopped reading when it got all shouty, and a quick scan doesn't show whether it's got actual sample code.
It's also been a long while since I wrote any C# for real, and even longer since I had to deal with .NET's XmlSerializer.
It used to be a pain in the backside to deal with XML in .NET if you wanted to just deserialise a file to an object. You'd need to mark up the class with attributes and stuff.
I remember being very happy when JSON.NET came out and we could just point at just about any standard object and JSON.NET would figure it out without any extra attributes.
I'm not sure if XmlSerializer ever caught up in that regard.
e:
Also, without seeing the code and where else it might be deployed it's not easy to know whether this is a case of over-engineering.
This same code might be deployed to a phone, webserver, lambda, whatever - so having an IConfigFileLoader might make 100% sense if you need to have another implementation that'll load from some other source.
Because if you have to invent the config file then isn't that creating a DSL and we're back to over engineering?