Entity Framework 4, che eredita rispetto all'estensione?

Question

Quali sono i vantaggi/svantaggi di ciascun metodo?

So che ho letto da qualche parte sia in un libro o su questo sito perché l'utilizzo di ereditarietà delle tabelle è pessima per Entity Framework 4.

Per esempio, perché non fare una tabella che ha un EntityID, DateCreated, DateModified e quindi ogni altra classe eredita quella nel framework di entità? Quindi le mie tabelle per tutte le altre entità non hanno bisogno di avere quelle colonne. Quindi posso avere una classe persona ereditare quella classe base, e poi una persona specifica ereditare una persona.

non sono certo dei vantaggi di questo, però diversa da scrivere uno script SQL più piccolo per generare il database ...

Svantaggi vedo sono che rende l'esecuzione di query/visualizzazione dei dati direttamente in SQL un grande dolore nel culo (tutte le informazioni rilevanti sono suddivise tra tanti tavoli), e ho anche chiesto al mio amico che ha detto:

"La cosa più importante che mi viene in mente è il fatto che non vorrei che il mio database fare affidamento sull'attuale struttura ereditaria della mia domanda, se, per qualsiasi ragione, volessi cambiare il design della mia applicazione in termini di ereditarietà, non avrebbe importanza perché i miei dati non sarebbero essere dipendente dal mio attuale design di sistema. Penso all'archiviazione dei dati proprio come questo: l'archiviazione. il database è normalizzato in base alla corretta progettazione del database, ma l'ereditarietà è una scelta programmatica dello sviluppo dell'applicazione, non della memorizzazione dei dati. solo questo mi avrebbe impedito di usarlo. l'ereditarietà è una cosa molto difficile da fare correttamente quando si tratta di progettare un'applicazione. è molto più facile cambiare il codice dell'applicazione che modificare e migrare i dati del database quando la maggior parte degli sviluppatori meno esperti si avvicina a un problema, si avvicinano con l'ereditarietà. l'ho fatto anche io quando ho iniziato a sviluppare. logicamente ha senso. tuttavia, una volta in via di sviluppo per lungo tempo si impara che la delega è davvero il modo migliore per andare (servizi di servizi di chiamata in caso di SOA) e che i servizi monouso offrono molto di più il riutilizzo di eredità ".

Quale ha senso anche per me.

Così

1) In generale, quali sono i pro/contro di eredità vs estendere
2) Nel mio esempio specifico di cui sopra, ciò che sarebbe più appropriato?
3) Se il mio esempio è schifoso per entrambi o entrambi, quale è un buon esempio per usare l'ereditarietà e per usare l'estensione?

Ho usato entrambi prima ma, come sono lontano da stagionato, non sono ancora sicuro di come gestire tutte le situazioni.

10 voti, 8 preferiti, oltre un centinaio di visualizzazioni e nessuno può espandersi? = (.

Answer 1

ho provato cosa simile come lei, e il problema principale che vedo, è che la u non può creare ObjectSet<T> per tipo derivato. Quindi non dovrete ObjectSet<Person> repository. Se si deriva tutte le Entità dall'entità BusinessObject, ad esempio, sarà possibile lavorare solo con ObjectSet<BusinessObject>. Se si desidera eseguire query solo su repository Person, è possibile scrivere query come Context.BusinessObjectSet.OfType<Person>().ToList() ma penso che non genererà SQL corretto sotto il cofano e prima otterrà le righe BusinessObject complete e quindi filtra le entità Person in memoria, quindi credo che avrà un enorme impatto sulle prestazioni.

Answer 2

Uno svantaggio dell'utilizzo dell'ereditarietà nel modello è che non sarà possibile eseguire la copiatura del modello tramite WCF Data Services (OData) poiché al momento non supporta entità derivate.

Answer 3

Sono un po 'in ritardo per la festa, ma ho avuto le stesse domande per quanto riguarda l'ereditarietà in EF e ho trovato un buon riassunto da leggere. È un excerpt from Julie Lerman's book Programming Entity Framework.

Dopo averlo letto, ecco le mie conclusioni sul tema:

1) In generale, quali sono i vantaggi/svantaggi di eredità vs estendere - I pro davvero dipendono dalla strategia di tavolo che si sceglie. Vedi How to choose an Inheritance Strategy - MSDN Blog. Tuttavia, sono solo dei "professionisti" nell'ipotesi che tu abbia già deciso di utilizzare l'ereditarietà. E questa non è una decisione da prendere alla leggera.

I contro sono molti, ma la più grande è l'impossibilità di aggiungere un'entità esistente nel database come entità derivata. Ad esempio: ho uno studente che eredita dalla persona. C'è un record personale per John Smith. Qualche tempo dopo ho bisogno che John Smith sia uno studente. Bene, peccato Non e possibile. (Almeno non senza aggirare EF con una procedura memorizzata).

2) Nel mio esempio specifico sopra, cosa sarebbe più appropriato? - Nel tuo esempio dovresti semplicemente aggiungere quelle colonne (entityId, datacreated, datododified) alle tabelle che ne hanno bisogno. Potresti usare un Tipo Complesso per datacreated e datododificato, ma ciò non sarebbe necessario a meno che tu non sia un ragazzo DRY molto severo. Anche allora, potrebbe essere eccessivo. Il motivo è che una volta che hai un'entità, non puoi mai aggiungere quell'entità ad un'altra tabella derivata. Una Persona (che è una BaseEntity) non può essere aggiunta successivamente come Studente. Inoltre, scrivere query LINQ sarebbe molto più complesso del necessario. Alex lo ha già dimostrato.

3) Se il mio esempio è crappy per uno o entrambi, quale è un buon esempio per l'utilizzo dell'ereditarietà e per l'utilizzo dell'estensione? - In genere, se è possibile creare un abstract di tipo base, l'ereditarietà potrebbe essere il funzionante. Ma dovresti comunque considerare prima altre opzioni. Se il tuo tipo di base verrà creato direttamente da qualche parte, usa solo la composizione. L'ereditarietà diventa molto fastidiosa quando si tratta di interrogare e inserire effettivamente i record.

In sintesi, solo perché è possibile eseguire l'ereditarietà in EF non significa che si dovrebbe. Se riesci a farla franca con un design senza ereditarietà, allora fallo con tutti i mezzi.