   [C#] [XML] Saving settings from multiple classes and XML
  I'm experimenting with designs to save/load data from multiple classes with different properties in XML format.Currently I'm thinking that I should create a separate settings class that would contain the serialisable properties for each class.Something like this:    class EntitySettings : Settings    {   [Serializable]   public float Mass;    // Mass   public Vector3 Scale; // Dimensions   public Vector3 Position;   // World position   public Vector3 Rotation;   // Global orientation   public Actor_Type Type;    // Type of actor    }Different classes would have different settings classes that could be assigned to them.Alongside this, I was wondering how to approach the saving of multiple setting classes.  I've thought about creating another class that housed all settings in a dictionary:    class SaveData    {   Dictionary<string, Settings> entitySettings = new Dictionary<string, Settings>(1000);   public void RemoveSettings(string name, Settings settings)   {  entitySettings.Remove(name);   }   public void StoreSettings(string name, Settings settings)   {  if (!entitySettings.ContainsKey(name))  { entitySettings.Add(name, settings);  }  else  { entitySettings[name] = settings;  }   }    }That way, one dictionary could be serialized/deserialized come save/load time and the settings can be dealt with accordingly.What do you guys think of this idea.  Is this a good approach?   
  (sidenote: attributes always only apply to the next entity)I would go with different classes. Or better, I actually do so in picogen (a C++ terrain synthesizer and renderer (and GUI)). That way, I can build up hierarchies very easily. I can reuse e.g. serializable Vectors or Colours at many places. I also plan to support importing partial scenes into the editor, i.e. allow e.g. users to define awesome terrains, but without the need to unecessarily export a whole scene.It would even be easy to build up a scene repository by having a new aggregate of scenes.pre-edit: I realise my last example is basically what you want to do, but without interfaces and a tad more verbose. I went a more static way, which would go like class Scene {    List<Volume> volumes;    List<Primitive> primitives;}et cetera (real example scene from picogen, it reflects the class structure very much). I think it is simpler and on the client side less hairy to grasp.Btw: I think it is a good idea to seperate serialization-classes from the rest of your code. Programs mutate, so do its entities. But save-file formats shouldn't change incompatibly too often.   ;  Excellent, I'm glad I'm on the right path.I was a little confused as to how I should update settings when it comes to saving.Should I:1) Update the settings class each time the entities properties have changed?OR 2) Update the settings (based on the current property values) when hitting the save button?ORSomething else?I am uncertain how I could grab the entities properties at any point to be stored into settings.  The settings class will only be serialized when the save button is hit so it doesn't matter if its values change.Any ideas?   ;Quote:Original post by Spa8nkyExcellent, I'm glad I'm on the right path.I don't know if it's the one right path :)But knowing about .net serialization, and knowing about how I do it in picogen, I'd personally stay with the picogen way, as for it's non-invasivity.Quote:I was a little confused as to how I should update settings when it comes to saving.Should I:1) Update the settings class each time the entities properties have changed?OR 2) Update the settings (based on the current property values) when hitting the save button?ORSomething else?I am uncertain how I could grab the entities properties at any point to be stored into settings.  The settings class will only be serialized when the save button is hit so it doesn't matter if its values change.Any ideas?Personally, I "convert" the settings to the real stuff upon user-load or upon rendering, and upon user-save. Doing it each time a value is changed would require some overhead, for no benefit (if the app crashes, the tweaks are away anyways, unless user presses "save"). Of course it comes at no price if you interleave runtime data and serialization data, but then you'd also pay the price for either breaking config-files from time to time, or for having to maintain some static interface directly in your class.Again, I don't know if this is the one right way, but it works very well for me (better than the serialization stuff at work, which I know into pretty detail, as I've written some extension method to add xml-comments to savefiles) :)   