Best Practices for Configuration Management software development (WPF C#)
This case its like a lot of radio buttons, dropdowns (with 10, 20, 600+ options), strings, integers, floats.
A lot means 1000s of each of those.
Configuration s/w means: device A's IP is 000.000.000.000 its FUNCTION is enabled and so on
What are the best approaches for managing this configuration storage and management? Would a relational database (SQL) be more efficient, or would a NoSQL or file-based approach (XML/JSON) be better for handling dynamic settings and historical data?
Additionally, are there any best practices for keeping the UI in sync with fast-changing data in a WPF C# application?
10 Replies
Your combo boxes need to be searchable
Not sure what you mean by 'FUNCTION'
A relational database is faster in returning queries but slower in r/w speeds generally speaking
Your data structure will determine which one works best
But definitely do not go the file-based approach
For UI to listen to data changes, you can use INPC or simply the MVVM toolkit
my bad for not specifying, I meant it as a combo box
oh okay, will check it out for sure, thanks
yes but relational and nosql are for different aims, relational keeps relations between data so it maintains consistency, while nosql is either graphs or flat
in this case if the filter is just a simple ip i think a regular sql would be enough
probably sqlite, if you have no other needs
okay
understandable
if you don't mind let me ask this
for most tables if there is no relations to one another. would the file based ones would just do the work. something like xml or json. so that the deployed software won't have to ask for permissions that a sql db might ask.
that's why i said use sqlite, it's an in memory db in the process of your program, not an external service
i would reserve using a file only for special cases with real constraints
im not saying to me would be out of question, but there should really be reasons to do that
hmm
okay
thats really helpful I'll see if that (sqlite) works out for me.
thanks
usual requirements are if you need to update this data remotely (or if there are deploy procedures), if multiple users need to connect to it contemporaneously, if you have to do backups of some sort
for stuff like that a full fledged db would be better, if not sqlite is fine
oh
i see
okay. got it
sorry to continue ranting, one last thing: leaving a text file in the folder that your program would read to get the data leaves the file open to modifications from users, and so one day then they'll call you to say "hey, i can't start the program" (had this happen to me in the past); file would always need to be parsed and be verified in its entirety, which then would have the consequence that you (or whoever) would start having multiple versions: data.json, data_bk.json, data (1).json, data.json-20250219, data.json.last, and so on
yeah I did mention his data structure would be the final decision maker