It appears the generalized, correct way to persist a Dictionary to a database would be the way it's Enumerated, since tables are essentially Sets with a loose concept of order - just like IEnumerable. That is, a Dictionary is enumerated as IEnumerator< KeyValuePair< TKey, TValue > >, and so the table should have 2 columns:
Key
Value
From there you have the existing EF conventions of Complex Types, where Key might actually be an object with many properties, and value as well. For example a dictionary of user objects might look like:
Username (TKey)
Address1 (TValue)
Address2 (TValue)
It's unfortunate this generalized pattern isn't built-in to EF; it ought to be proposed.
Instead of developing a specific type for your solution, you could use a generalized class that produces a Data Annotated version of KeyValuePair<>.
public class EFKeyValuePair<TKey, TValue>
{
[Key]
public TKey Key { get; set; }
public TValue Value { get; set; }
}
I'm not certain how you'd ensure the table names would be written out in a logical and verifiable way however without inheriting this class and adding an attribute to each subclass. Perhaps the Fluent API could get you this final step (which I'm not very familiar with).