Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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; }


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?
share|improve this question
I'd call this approach "Horrible", frankly. Strings are a terrible key for data, they're easily typoable and any issues with them are only thrown up at runtime. If for some reason you cannot use properties, I see no downside to having a dictionary of SomeEnum -> Object, which still sucks due to losing type safety on one end, but gains a very little back on the other. – Phoshi Nov 7 '13 at 14:19
@Phoshi yes, this is essentially taking a dynamic language approach and applying it to a statically typed language, so you sacrifice static typing for extensibility. – Mark Heath Nov 7 '13 at 15:01
Except that there are better ways to achieve this sort of flexibility that don't end up killing type safety quite so bad, and I'm not sure what benefit you're getting here other than it being quicker to develop that component. Now, if there aren't many other components, that's totally valid, but losing type safety in your data storage engine is insane in a larger project. At best, you're going to litter your code with instanceof and (Casting). – Phoshi Nov 7 '13 at 15:50
No, it's instanceof that this approach eliminates since there are no derived types any more. I didn't want to bloat the question with long details about why I'm interested in this approach, but a big part of the driver is getting rid of instanceof, and dealing with the challenges of needing to deserialize objects from any previous (or future) version of the application. – Mark Heath Nov 7 '13 at 15:58
If you're never doing runtime typechecks then you can only sanely treat everything as "object". I mean, I guess you can treat everything as strings if you ToString everything before use, but this is still all of the disadvantages of loosely typed programming without the metadata that actually makes that work. Treating everything as Object and never changing types isn't making the type system more flexible, it's making the type system work against you for no benefit. – Phoshi Nov 8 '13 at 9:24

If you're taking this approach, why stick with a traditional relational database? NoSQL databases like MongoDB let you apply "fuzzy schemas" to data which should allow different versions of the software to pick out documents that it expects and leave out the others (or fill it with nulls)

share|improve this answer
yes, essentially I want the benefits of schemaless objects that you get with nosql, but I'm stuck in relational database world because the application in question is already installed on thousands of sites worldwide. Changing database would be virtually impossible at this stage, so I'm considering this as a kind of poor man's NoSQL, possibly using JSON to serialise the objects. – Mark Heath Nov 9 '13 at 9:50
Ah, so you're stuck with the database already. Are you using SQL Server? I don't know how this feature works, performance-wise, but there's an XML datatype in SS2005+ that lets you do [XPath queries](…. You might be able to use this to build what you're looking for. – nemec Nov 9 '13 at 21:15

You should probably make this decision based on your actual data model. If it is relatively static then I think you would be better taking the hit of changing your schema and updating your classes and DTO's. It may sound like a lot of work but if you are C# and Sql land you will probably end up with a better solution in the long run.

You may also want to consider a hybrid approach where most of your properties are strongly typed but also have a dictionary for more dynamic or sparse properties.

Ideally to get a nice solution for your situation you'd either switch to a dynamic language or schemaless database or both.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.