Esempi per Entity Framework 4: mappatura dei POCO nel database EAV?

Question

Il nostro cliente pubblicizza prodotti ma gli attributi del prodotto sono molto diversi tra loro. Ci sono quasi tante "classi" di prodotti quanti sono i prodotti.

Inizialmente, abbiamo creato un database EAV in cui abbiamo aggiunto e rimosso gli attributi per ogni "classe" di prodotto. Il tutto funziona molto bene, ma la complessità è anestetizzante. Questo è il Database # 1.

Alla fine abbiamo creato un insieme di campi comuni per rappresentare tutti i prodotti (POCO), spostando i campi "extra" in un campo XML "catch all". Questo è il database n. 2.

Ora abbiamo alcuni clienti che utilizzano il vecchio e alcuni clienti che utilizzeranno il nuovo. Non volevamo aggiornare il vecchio fino a quando non avremmo dovuto farlo, ma di tanto in tanto abbiamo delle modifiche che richiedono più tempo del necessario a causa della struttura EAV.

Domande:

1. Eventuali esempi là fuori su come codificare EF a persistere pocos a un database EAV (in cui si dispone di una tabella di nomi di campo e una tabella di dati)?
2. Dovremmo semplicemente cancellare il database e scrivere tabelle "normali" per tutti quei vecchi clienti, dato che abbiamo delle modifiche di volta in volta?

Normalmente si riferisce al modulo normale Boyce Codd.
Abbiamo gestito il vecchio database estraendo la sua struttura nel software, quindi eseguendo il mapping su POCO nel repository.

Answer 1

tavoli EAV sono generalmente un business disordinato, e Joe Celko (in Avoiding the EAV of Destruction) e un sacco di altri esperti del settore (ad esempio Five Simple Database Design Errors You Should Avoid) giustamente in guardia contro l'uso di EAV costruisce troppo.

Tutti i critici del database a parte: come sarebbe un oggetto in .NET basato su un tale EAV? Potrebbe avere un numero qualsiasi di proprietà di qualsiasi tipo, quindi, in pratica, dovrebbe essere un oggetto "universale" che può assumere qualsiasi forma, praticamente.

Questo pensiero mi fa accapponare la pelle e va contro i concetti più basilari di un linguaggio fortemente tipizzato: sì, puoi fare cose del genere in un linguaggio dinamico come Ruby e Python, ma in C#?

L'unica soluzione possibile, si dispone potrebbe venire con il nuovo "dinamico" digitare NET 4.0 e l'ExpandoObject - un oggetto che può assumere qualsiasi forma, avere proprietà di qualsiasi tipo, e in fondo di essere quello che vuoi che essere.

Si potrebbe immaginare una mappatura tra una struttura EAV in SQL Server e un ExpandoObject in C# 4.0 - ma dubito fortemente che il team EF abbia fatto qualcosa in questo senso e, onestamente, non credo che lo faranno in qualsiasi momento presto. Ma questa potrebbe essere una possibilità per te di esplorare.

Per l'ExpandoObject, si veda:

• sua MSDN documentation
• C# 4.0: Introducing the Expando Object
• qui su SO: What are the true benefits of ExpandoObject?
• Dynamic in C# 4.0 - Introducing the ExpandoObject