Advantages of interface metadata in a database

I'm working on an application where the interface metadata is stored in a database.

Basically the C# .NET application reads the positions, size开发者_JAVA技巧 and text of buttons, labels, radiobuttons, etc.. from SQL Server tables.

As far as I can tell, who ever wrote the application entered all of this information by hand as I cannot find the tool (or any hints of a tool) used to do this.

At any rate, I find it rather tedious maintaining this information without some sort of tool, and I'm wondering what the advantages are of such an arrangement, as opposed to simply using the Visual Studio interface designer?

---

Maybe it's just a different way of implementing an INI file?

There's nothing really stopping you from doing it this way, though there may have been a reason why it was done that way. Perhaps there was some reason why files couldn't be written to the local hard drive or keys stored in the registry.

---

I guess it would be an advantage if you wanted to be able to modify those things without re-compiling. It may also allow you to avoid forking the source and then having to maintain both variants. Maybe the developer was thinking about internationalization, which certainly affects labels and may also (as a consequence) affect size and position too. In principle, you just need to swap in new table contents you're ready for a different language.

I can see keeping UI metadata for each field as opposed to each control in order to ensure that the field is presented consistently throughout an interface (same label, format, even control, e.g., radio button versus dropdown list). If you need to change the label for a field used in 8 different windows, then you only have to fix it in one place.