Tabella per tipo di calcestruzzo in Entity Framework Core

2

Sto provando a portare il codice dall'entità framework 6 (EF6) all'entità framework core 2.0 (EF-Core) e sono finito in un vicolo cieco.

Nel mio codice EF6, ho una classe base chiamata Record che definisce le proprietà di base e i metodi di tutti i tipi di Record . Questa classe base fornisce funzionalità e proprietà comuni per tutti i diversi tipi di record.

Esistono molti tipi diversi di record che derivano dalla classe base Record . Ognuno di questi Records ha proprietà aggiuntive specifiche per quel tipo di record. Ad esempio, ho una classe CustomerComplaint e una classe TrainingRecord che entrambi derivano dalla classe Record . Come puoi essere in grado di indovinare, il due Records ha proprietà molto diverse; tuttavia, entrambi condividono funzionalità comuni quali modifica, invio, controllo dei permessi, ecc.

Il mio problema è che EF-Core non supporta le gerarchie di ereditarietà di tipo Table per Concrete (ad es. una tabella separata per ogni tipo di record). Attualmente, EF-Core supporta solo la mappatura delle gerarchie di ereditarietà in schemi Tabella per gerarchia (ad es. una singola tabella con le proprietà di tutte le sottoclassi e un valore discriminante per differenziare tra le sottoclassi). Dato che ho una dozzina di tipi diversi di record, uno schema Tabella per gerarchia risulterebbe in una mostruosità di una tabella all'interno del mio database; creerebbe una singola tabella con colonne per tutte le proprietà di tutte le sottoclassi dei miei record!

Come dovrei implementare una soluzione alternativa a questo problema? Una soluzione a cui ho pensato è di rompere la gerarchia in interfacce e servizi. Potrei condividere proprietà comuni definendo un'interfaccia con quelle proprietà e potrei condividere codice comune spostando il codice in una classe di servizio che opera solo su oggetti che implementano la mia interfaccia.

    
posta Tyler K 14.11.2017 - 02:02
fonte

1 risposta

1

Anche se ovviamente ci potrebbero essere troppe colonne in una tabella, la ragione principale per cui questo è un problema è quando si tenta di gestirle tutte nello stesso momento, il che sarebbe un problema se si scrive il proprio SQL -statements.

Entity Framework è in effetti abbastanza efficace nella gestione di Table-Per-Hierarchy, nel tuo codice vengono visualizzate solo le colonne effettivamente utilizzate dalla sottoclasse specifica. Quindi non è un grosso problema come sarebbe se lo sql fosse scritto a mano. Nel tuo codice sembrerà che ci sia una tabella diversa per ogni sottoclasse.

Se il tavolo è troppo grande per te, allora la tua soluzione suona bene. E sarebbe il modo in cui lo farei.

Non l'ho provato, ma forse puoi avere ciascuna sottoclasse ereditata dalla stessa classe di base, ma non avere una DbSet<> per quella classe di base che risulta in Entity Framework che non usa la Tabella per Gerarchia ma tabelle separate.

    
risposta data 15.11.2017 - 00:02
fonte