What pattern(s) am I supposed to use for this situation?

Question

For several applications I made for my current client I have shared user accounts. This means that each account in one application should exist in the other applications.
Each application has it's own set of settings.
The number of applications and the settings themselves will be the parts that really change over time so I want to separate them.

The data store is accessed through an IRepository class (XMLRepository, SQLRepository etc). They abstract the actual data access logic away. The SettingsService class should be able to get an ISetting class as followed

public T GetSetting<T>(IUser user) where T : ISetting

Since the fields of an ISettings class will be different for each type I would reckon that it's the actual Settings class that should know how to fill it's own fields, but it doesn't know how to get the values.
The repository however would know how to access the data, but it doesn't know where to put them.

The GetSetting is actually a factory method if I'm not mistaking. I have the feeling this problem is not something new and there is probably a good pattern to solve this.

What are my options?

Answer 1

You will need some sort of factory for each concrete type of ISetting that can create the concrete SomeSetting instance from data returned from a Repository.

How such a factory should work depends on how you envision the settings persistence schema. Do you have a custom schema for each type of ISetting, or do you simply serialize and deserialize settings in a BLOB/XML?

In the first case, you will need a custom Repository for each settings schema. This is the easy scenario, since each specialized Repository will simply act as the custom factory.

In the other case, you can save metadata together with the BLOB that either stores which custom factory to use to deserialize the BLOB, or alternatively simply the type of the serialized BLOB (and you can then use the serialization API of .NET to serialize and deserialize the object).