Because if you have to invent the config file then isn't that creating a DSL and we're back to over engineering?
Because if you have to invent the config file then isn't that creating a DSL and we're back to over engineering?
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.
Not really. The one thing that exists to make this easier is xsd.exe, which can generate the code for these classes from and XML Schema file.
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
I had a ton of scripts that generated classes from XML and SQL Tables. I forget exactly how.