How to represent (class) data for GUI generation?

I'm trying to make a small application that can edit the data files from an earlier project. I have access to that projects "data classes" (pretty dumb classes whose main purpose is to expose it's (public) member variables) that can read/write to the files. All I have to do is make a GUI that can edit the different member variables that each data class have (preferably without modifying the data class) and I'm trying to figure out how to do this so that it will be easy to adapt for future changes/additions. (I don't feel like I can assume that all member variables should be editable, might only be a selection of them).

All the data can be converted to/from strings (numbers and text) and I don't see much problem in generating textboxes and/or something like a DataGridView in the GUI, but I'm not sure as to how I would like to represent the data needed to generate those.

My first thought was to use a list with all variables for each data class. With each row in the list containing the name+descri开发者_如何学编程ption of the variable (for the GUI), a pointer to the variable in the data-class and perhaps some form of validation-function for different variables. Store that list in a class that inherits the original data-class (and that implements an interface/abstract-class for any specific GUI-related functions (load/save etc.)).

The thing that makes me worry about this solution is just that I feel like this should be a somewhat common problem and I'm a bit rusty when it comes to OO and this solution smells like something I'd write if I had to do it in C.

There might even be a handy language construct, design pattern or something that is suitable but I don't know what to search for.

Does this approach even seem sensible?

Reflection is your friend in this case. Your data classes have a structure which can be explored using that class's Type. A Type is the base class for metadata concerning a class or structure, and includes methods to, for instance, get a list of all fields, properties and/or methods belonging to that class. The objects representing these class "members" can then be used to set or get field or property values, or invoke methods, given an instance of an object of that type.

A reflective algorithm can be designed to handle any object structure it is given, and it doesn't have to know those structures at compile-time unlike an algorithm based on static types. The downside? It's slow, and you get very little compile-time checking of your algorithm so it can fail at run-time in unexpected ways.

Here's something to get you started:

//statically set up an instance of some arbitrary object
MyClass myObject = new MyClass();
myObject.Field1 = "Hello";
myObject.Field2 = "World";

//This method is available on any object, and produces a Type representing the class definition
Type myType = myObject.GetType();

//C# also has a typeof() keyword that works when you have a static type and not an instance
myType = typeof(MyObject);

//Interrogate the Type instance to get its fields
FieldInfo[] fields = myType.GetFields();

//then, iterate through the fields to perform some (useful?) work.
//Here, we are outputting a list of paired field names and their current values.
//You will probably want to instantiate a Label and Textbox representing this value 
//and show them on a Form.
foreach(FieldInfo field in fields)
   Console.WriteLine(String.Format("{0}: {1}", field.Name, field.GetValue(myObject));

To handle editability, you will need some sort of record of what the user has permission to change and what they don't. If that information will never change from user to user, you can incorporate that information into the data class itself using attributes (which won't change the "interface" of the object; it'll still have all the same members, but those members will have additional metadata). You could also create another set of classes that implement an interface defining each one as a set of "field permissions" for its parent class, and then you can dynamically construct an instance of the "field permission" class with a Type instance representing your object definition, and knowledge of the name of the interface that field permission objects implement.