Aggiornamento 2019 / TLDR; passare a Entity Framework Core (o qualsiasi altra cosa)
Pur mancando alcune "Funzionalità", EF Core onora correttamente le chiavi alternative (alias vincoli univoci) oltre alle chiavi primarie e quindi fa un lavoro molto migliore per onorare l'algebra relazionale. YMMV altrimenti; almeno supporta correttamente molti altri schemi SQL.
Questo supporto aggiunto è stato nella versione (molto obsoleta) di EF Core 1.0 .. un po 'deludente che all'EF originale non sia mai stato risolto questo difetto di progettazione (ndr!).
Questo potrebbe essere correlato alla mia altra domanda - che sembra essere che:
Entity Framework è un terribile mapper di algebra relazionale 1 o;
(che spero) Sto trascurando qualcosa con SSDL / CSDL e il modello EDMX o le mappature EF in generale.
Ho un modello Schema First e lo schema è simile al seguente:
ExternalMaps
---
emap_id - PK
Melds
---
meld_id - PK
emap_id - >>UNIQUE INDEX<< over not-null column, FK to ExternalMaps.emap_id
Per la verifica, questi sono scritti come segue, il che dovrebbe tradursi in una molteplicità di ExternalMaps:1 <-> 0..1:Melds
2 .
ALTER TABLE [dbo].[Melds] WITH CHECK ADD CONSTRAINT [FK_Melds_ExternalMaps]
FOREIGN KEY([emap_id]) REFERENCES [dbo].[ExternalMaps] ([emap_id])
CREATE UNIQUE NONCLUSTERED INDEX [IX_Melds] ON [dbo].[Melds] ([emap_id] ASC)
Tuttavia, quando utilizzo il designer EDMX per l'aggiornamento dal database (SQL Server 2012), da zero, crea erroneamente la relazione Associazione / Chiave ExternalMap:1 <-> M:Meld
come ExternalMap:1 <-> M:Meld
.
Quando provo a cambiare manualmente la molteplicità per il lato Meld (tramite le proprietà "Set di associazioni" nella finestra di progettazione) su 1
o 0..1
, ottengo:
Esecuzione della trasformazione: la molteplicità non è valida nel ruolo 'Combina' nella relazione 'FK_Melds_ExternalMaps'. Poiché le proprietà del ruolo dipendente non sono le proprietà chiave, il limite superiore della molteplicità del ruolo dipendente deve essere
*
.
(Come per la mia altra domanda, questo sembra essere correlato a vincoli univoci che non sono correttamente registrati / onorati come chiavi candidate.)
Come posso fare in modo che EF onori la molteplicità 1 <-> 0..1/1
, come stabilito dal modello?
1 Anche se spero che non sia così, non ho fine al dolore quando provo a far mappare EF su un modello RA perfettamente valido: LINQ to SQL (L2S) non ha questo problema. Dato che la mia altra domanda non ha ottenuto una risposta banale per un ORM così popolare, sto perdendo fiducia in questo strumento.
2 È in base alla progettazione che l'FK non è dall'altra parte: "Sebbene non disporrà di chiavi esterne nullable". - Inoltre, non si tratta di un PK "condiviso", poiché questa risposta del 2009 suggerisce una soluzione.
Sto usando EF 6.1.1, VS 2013 Ultimate e non userò nessuna "funzionalità di sottotipo OO" - se questo cambia qualcosa.
EDIT sospiro :
La molteplicità non è valida perché le proprietà del ruolo dipendente non sono le proprietà chiave? (dal 2011) - questo è ancora il caso dell'ORM "pronto per le imprese approvate da Microsoft" in EF 2014 2015?
A questo ritmo la prossima volta che qualcuno chiederà perché EF non è stato usato, avrò una serie di motivi diversi da "LINQ to SQL funziona bene".
Il problema è che Entity Framework (da EF4 a EF6.1 e chissà quanto a lungo) non "capisce" la nozione di vincoli univoci e tutto ciò che implicano: EF maps Code First, non Relational Algebra * sigh *
Questa risposta per la mia domanda correlata fornisce un collegamento a una richiesta per aggiungere la funzionalità mancante e la somma:
.. Attualmente Entity Framework supporta solo i vincoli di riferimento basanti sulle chiavi primarie e non ha la nozione di un vincolo univoco .
Questo può essere esteso a quasi tutti i reami che si occupano di Vincoli Unici e Chiavi Candidate, incluso il problema della molteplicità sollevato in questa domanda.
Sarei felice se questa grave limitazione di EF fosse discussa apertamente e resa "ben nota", specialmente quando EF è propagandato per supportare Schema First e / o sostituire L2S. Dal mio punto di vista, EF è incentrato sulla mappatura (e sul supporto) solo di Code First come cittadino di prima classe. Forse in altri 4 anni ..