I'm noticing a trend towards using a dictionary of string to object (or sometimes string to string), instead of strongly typed objects. For example, the new Katana project makes heavy use of IDictionary<string,object>. This approach avoids the need to continually update your entity classes/DTOs and the database tables that persist them with new properties. It also avoids the need to create new derived entity types to support new types of entity, since the Dictionary is flexible enough to store any arbitrary properties.
Here's a contrived example:
class StorageDevice {
public int Id { get; set; }
public string Name { get; set; }
}
class NetworkShare : StorageDevice {
public string Path { get; set; }
public string LoginName { get; set; }
public string Password { get; set; }
}
class CloudStorage : StorageDevice {
public string ServerUri { get; set }
public string ContainerName { get; set; }
public int PortNumber { get; set; }
public Guid ApiKey { get; set; }
}
versus:
class StorageDevice {
public IDictionary<string, object> Properties { get; set; }
}
Basically I'm on the lookout for any talks, books or articles on this approach, so I can pick up on any best practices / difficulties to avoid. Here's my main questions:
Does this approach have a name? (only thing I've heard used so far is "self-describing objects")
What are the best practices for persisting these dictionaries into a relational database? Especially the challenges of deserializing them successfully with strongly typed languages like C#.
Does it change anything if some of the objects in the dictionary are themselves lists of strongly typed entities?
Should a second dictionary be used if you want to temporarily store objects that are not to be persisted/serialized across a network, or should you use some kind of namespacing on the keys to indicate this?
