Architecture for application that supports multiple user-input properties

Question

I've been puzzling over how best to architect an application I'm due to begin work on shortly and nothing simple is coming to mind. Maybe someone else can see something that I'm missing.

The objective is pretty simple -- construct an app in C#/WinForms to allow the user to specify a file to be loaded, then visualize that file's contents in 3D, allow the user to tweak some properties, and then run a simulation.

The tricky part is the back-end. I have two files to load.

The first isn't specified by the user, but rather comes out of an older C++ application and is XML format and will be loaded automatically. The XML file describes its object structure - each class, its properties, and the corresponding min, max, and default values for those properties, as well as a text field documenting the property. This file is used to set up/define the classes/properties. This file continues to change on a fairly regular basis, so the objective here to is import these XML definitions so as not to link this new UI too closely with the older app.

The second file contains the input that is relevant to the user. This file describes what objects will be used and the values relevant to a subset of the classes/properties described in the first file.

That's it.

As I said, I've considered several ways of doing this, but they all seem archaic. One method I've thought about this: First, create a factory/dispatcher that reads and constructs a class of type 'Loadable' to represent those classes defined in the XML; then create a generic 'Property' to store the properties themselves and store them in a collection of some sort within the Loadable object. My thought is that this way, I can reference those Loadables later on when loading the user's file or when pulling them up in a PropertyGrid for user-editing.

Thoughts? Am I on crack? Is there a simpler way to tackle this that I'm not seeing through the trees? Any comments would be welcome.

Answer 1

I am not sure if this is what you are looking for, but every time I deal with an XML settings file (which is pretty much what your first file is boiling down to) I just create a class whose sole purpose in life is to retrieve those values and give them back to me. This way I don't have to read all the properties or settings right away, but simply call this class that will check out the XML for the specific one that is needed and give it to me right then and there and then let GC do it's thing. Like I said I am not sure if that is what you are looking for, but it is my idea to help you out a bit.

Answer 2

Your first file is about the metadata for your entities. (From your descriptions) you could model it like this (very close to what you described):

public class Class {
  public List<Property> Properties;
}

public class Property {
  public string Name;
  public float Min;
  public float Max;
  public float Default;
  public string Documentation;
}

Then, your second file is the data associated with that metadata, you could model it like this:

public class Instance {
  public Class Class;
  public List<PropertyValue> Values;
}

public class PropertyValue {
  public Property Property;
  public float Value;
}

Note: use proper constructs, like read-only properties and constructor parameters to instantiate your objects, as appropriate. (I've used fields just as an example.)