Separate settings and implementation class hierarchies

Question

We use XML serialization to store class settings. Each setting-class has (but doesn't reference) corresponding implementation-class. Therefore we can easily make a "settings dll" without any dependencies. That's why there is no implementation code included inside setting-classes.

What would be the best way to construct implementation-classes when having an array of setting-classes?

Reflection-activator? Visitor? Anything else? Or can you propose another approach for having settings classes independent from implementation?

---

Added:

1. We have a complex structure with arrays and nested objects which doesn't work well with System.Configuration.
2. We are not serializing directly to a file.

Example structure:

 public class GameMap
 {
 public string Name { get; set; }
 public ItemSet[] Lootables { get; set; }
 public class ItemSet
 {
 public Item[] Items { get; set; }
 public abstract class Item
 {
 public float Probability { get; set; }
 public Vector3 Position { get; set; }
 }
 public class Coin : Item
 {
 public int Count { get; set; }
 }
 public class HealthRestoration : Item
 {
 public bool ApplicableToDragons { get; set; }
 }
 }
 public Ability[] Abilities { get; set; }
 public class Ability
 {
 public string Name { get; set; }
 public int Cooldown { get; set; }
 public Effect[] Effects { get; set; }
 }
 public abstract class Effect
 {
 // some nested data...
 }
 }

Each setting-instance can be used to create a corresponding implementation-instance. E.g. HealthRestoration implementation-class contains logic to actually restore a game character hit points and it needs to have its setting-instance to know whether the item is ApplicableToDragons.

• RubberDuck: You're using XML Serialization, but not serializing to disk... Not that it matters for the context of the question really, but where are you serializing to then?
• Vlad: @RubberDuck Actually we are keeping that xml in database. This is a kind of static data which is loaded on application start and never used in queries except SELECT * .
• RubberDuck: Okay, so you're still serializing to disk, just not the local disk, but the db's disk. There's another good reason to go with a centralized access point. If you decided later to swap DBs or to go with a local setting file, or whatever, you have a nice abstraction that could easily be swapped out. Why are you so concerned with separating the settings from the class that's getting serizialized anyway? In my experience, such classes are really just POCOs with next to no logic in them, data models really. What benefit do you hope to get from separating the two? What do you want to separate?
• Vlad: @RubberDuck we need to seperate it because 1) the logic part can have its own state (like timers may be) which is not meant to be serialized ever. 2) the logic part have multiple dependencies and interacts with other components. 3) at some time we'll consider to make custom editors. they shouldn't pull all those dependencies.
• Flater: Based on your current description, this seems like a whole lot of work for no real payoff. You're gong to be stuck having to change the settings dll when the application needs a new setting to be added/changed/deleted. I don't quite see the benefit here. I would see the benefit of e.g. a generic serialization library (with meaningful features that extend it beyond mere serialization) which allows the consuming application to pass its own objects to it (similar to how JSON.Net works).