Ho visto questo commento su MSDN (link e link): "Si noti che le associazioni indipendenti dovrebbero spesso essere evitato in quanto le cose come N-Tier e la concorrenza diventa più difficile"EF4 Associazioni indipendenti - Perché evitarli?
Sono nuovo di EF4 e sto creando un'app di rete n-Tier. Sembra una trappola importante. Qualcuno può spiegarmi cosa significa?
Penso che sia una preferenza personale. Originariamente, EF è stato creato per usare solo indep. associazioni e allineati con un approccio ERM più classico. Tuttavia, molti di noi dev sono così dipendenti dalle FK da rendere la vita molto complessa. Quindi MS ci ha fornito FK in EF4, il che significava non solo avere l'FK come proprietà nell'entità dipendente, ma le relazioni sono definite attraverso vincoli nel modello concettuale piuttosto che sepolti nelle mappature. Esistono ancora alcune relazioni che è possibile definire solo con un'associazione indep: da molte a molte e chiavi esterne univoche. Si noti che se si prevede di utilizzare Servizi RIA (non sembra tale), RIA riconosce solo le associazioni FK.
Quindi, se si preferisce sfruttare le associazioni indipendenti, è comunque possibile utilizzarle in EF4. Sono totalmente supportati. Ma come James suggerisce, ci sono alcune trappole da tenere in considerazione ... cose che dovrai fare in modo più esplicito a causa del modo in cui l'EF lavora in particolare con i grafici. O in quel caso in cui desideri solo quell'FK, ad esempio, hai l'ID di un cliente ma non hai l'istanza. Potresti creare un ordine ma senza quella bella proprietà FID CustomerID, devi fare qualche giocoleria in più per ottenere quel CustomerID lì.
h.
Se sei nuovo di EF e, a partire da EF4, la semplice risposta è ignorata: quasi certamente utilizzerai le associazioni di chiavi esterne anziché le associazioni indipendenti.
Un'associazione chiave esterna è supportata da una relazione di chiave esterna nel database e questa relazione è esplicitamente descritta nel modello concettuale. Questo tipo di associazione è nuova per EF4 e capisco che è una concessione che segue i problemi che le persone hanno avuto con le associazioni indipendenti.
Strettamente se si desidera separare lo schema di archiviazione e lo schema concettuale (che è il tipo di punto EF) non si vuole che lo schema concettuale sappia cose come le chiavi esterne in quanto si tratta di un database (ad es.) concetto. Le versioni precedenti di EF seguivano questo approccio e abbiamo questa cosa chiamata Associazione Indipendente.
Pensare alle associazioni indipendenti come associazioni tracciate da EF senza la conoscenza della chiave esterna sottostante. EF lo supporta ancora, ma ha delle debolezze significative.
EF4 in VS2010 utilizzerà le chiavi esterne e creerà relazioni con le chiavi esterne a meno che non le dica diversamente. Nel complesso questi lavori come ti aspetteresti. Ci sono ancora alcuni trucchi - ad es. intorno alle eliminazioni a cascata.
Se volete saperne di EF - posso raccomandare questo libro:
http://learnentityframework.com/learnentityframework/
Tutto quello che volete sapere, molto chiaramente spiegato.
Okeedoke. Ma quali sono specificamente i problemi causati da n-tier e concorrenza? – anon
Bene, la differenza principale oltre alla differenza dello schema è che un'entità con un'associazione indipendente non espone la chiave esterna nel livello concettuale. L'associazione viene mantenuta in un oggetto separato. A seconda di come si progetta l'applicazione, è più complesso passare queste informazioni aggiuntive tra i livelli. Le associazioni di chiavi estranee sono molto più facili da utilizzare poiché è possibile impostare la chiave esterna direttamente sull'entità o modificare l'entità/entità entità esposte correlate. –
"Meno facile lavorare con" nella mia mente non significa necessariamente "evitare". Quest'ultimo suggerisce che ci sono specifiche insidie. Ci sono articoli là fuori su queste trappole? (Ho il libro di Julia Lerman, BTW.) – anon