Entity Framework 4 POCO ze Słownika

Question

mam (Object Plain Old CLR) POCO

public Foo 
{ 
    public virtual int Id { get; set; } 
    public virtual Dictionary<string, string> Stuff { get; set; } 
    public virtual string More { get; set; } 
} 

Stosując podejście model first (tzn nie mam jeszcze modelu danych), jak będzie sobie radzić utrzymującego rzeczy (Słownik)?

Answer 1

To nie jest prawdziwa odpowiedź na to pytanie, ale ponieważ nie ma innych odpowiedzi, podzielę się tym, co zrobiłem.

Po prostu utworzyłem nowy typ {Id, Code, Text} i zastąpiłem mój słownik listą tego typu. I wtedy coś jak to zrobić, aby dostać klucze, wartości, czy odnośnika:

List<string> texts = (from sv in q.SelectableValues select sv.Text).ToList(); 
List<string> codes = (from sv in q.SelectableValues select sv.Code).ToList(); 
string text = (from sv in q.SelectableValues where sv.Code == "MyKey" select sv.Text).First(); 

W moim przypadku liczba wpisów w słowniku wydaje się być niewielka. Jednakże, zobacz this question dla kwestii wydajności, gdy słownik/lista jest duża.

Answer 2

Wygląda na to, że uogólnionym i prawidłowym sposobem utrwalania Słownika w bazie danych byłby sposób jego wyliczenia, ponieważ tabele są w zasadzie Zestawami z luźną koncepcją zamówienia - tak jak IEnumerable. Oznacza to, że słownik jest wyliczane jako IEnumerator < KeyValuePair < TKey, TValue>>, a więc tabela powinna mieć 2 kolumny:

Key 
Value 

Stamtąd masz istniejące konwencje EF złożonych typów, gdzie klucz może faktycznie być obiektem o wielu właściwościach, a także wartości. Na przykład słownik obiektów użytkownika może wyglądać następująco:

Username (TKey) 
Address1 (TValue) 
Address2 (TValue) 

To niefortunne, że ten ogólny wzór nie jest wbudowany w EF; powinien zostać zaproponowany.

Zamiast opracowywania określonego typu rozwiązania, można użyć uogólnionej klasy, która tworzy wersję klucza KeyValuePair z komentarzem do danych <>.

public class EFKeyValuePair<TKey, TValue> 
{ 
    [Key] 
    public TKey Key { get; set; } 
    public TValue Value { get; set; } 
} 

Nie jestem pewien, jak chcesz zapewnić nazwy tabel byłyby rozpisane w sposób logiczny i możliwy do zweryfikowania sposób jednak bez dziedziczenia tej klasy i dodanie atrybutu każdej podklasy. Być może Fluent API może dostarczyć ci ostatni krok (z którym nie jestem zaznajomiony).