Livelli multipli di ereditarietà negli abeti del codice EF

Sto cercando di capire come gestire l’ereditarietà per più tipi. Ho un progetto Code First / EF / MVC esistente che ha dati in tempo reale in un ambiente di produzione. Il sistema usa un tipo chiamato “Documento” sul quale possono essere eseguite molte funzioni e ci sono molte tabelle associate che possono collegarsi al DocumentID.

Attualmente esiste un tipo di documento più differenziato, un ordine di acquisto che implementa proprietà più specifiche, come una raccolta di “OrderLines” che fanno riferimento a un prodotto, una quantità e un prezzo unitario. Esistono anche altri campi specifici per l’ordine d’acquisto. Oltre a distinguere dal tipo di documento di base in “OrderLines”, l’ordine di acquisto è un documento di fornitura laterale e, in quanto tale, è un “fornitore” di terze parti. Potrebbero esserci altri documenti sul lato dell’offerta che hanno anche un fornitore come terze parti in futuro.

Ora sono pronto per implementare un nuovo tipo di documento che sarà Demand Side, nel senso che avrà una terza parte chiamata cliente. Ha anche una collezione di OrderLines.

Il mio sistema è attualmente impostato come TPH, quindi la tabella si chiama “Documenti” e c’è una colonna discriminante che dice che i documenti all’interno sono ordini d’acquisto.

Come posso aggiungere il nuovo tipo e utilizzare l’ereditarietà per implementare la raccolta OrderLines e il link CustomerID / Customer? Sembra che c # non possa fare ereditarietà multiple, quindi quanto segue sarebbe fuori discussione:

Documento -> OrderLinesDocument -> PurchaseOrder

Documento -> OrderLinesDocument -> Fattura

Documento -> VendorDocument -> PurchaseOrder

Documento -> CustomerDocument -> Fattura

Dove la class media implementerebbe i campi che potrebbero essere comuni a molti documenti ma non a tutti i documenti?

C’è un modo per ottenere questo risultato usando le interfacce, e ancora l’EF calcola correttamente le tabelle?

L’ereditarietà potrebbe essere complicata in molti modi – quindi il mio consiglio è di andare ‘facile’ con esso.

Ma solo un tipico progetto OO qui produrrà tavoli e strutture utilizzabili. Forse qualcosa del genere potrebbe funzionare per te …

 public class Document { public long ID { get; set; } public string Name { get; set; } } public class OrderLinesDocument : Document { public ICollection OrderLines { get; set; } } public interface IVendorDocument { ICollection Vendors { get; set; } } public class VendorDocument : Document, IVendorDocument { public ICollection Vendors { get; set; } } public interface ICustomerDocument { ICollection Customers { get; set; } } public class CustomerDocument : Document { public ICollection Customers { get; set; } } public class PurchaseOrder : OrderLinesDocument, IVendorDocument { public ICollection Vendors { get; set; } } public class Invoice : Document, ICustomerDocument { public ICollection Customers { get; set; } } 

La soluzione più semplice IMO sta usando TPH (solo ‘così com’è’).

Ma come ho detto, attento con esso – e potrebbe non funzionare per quello che hai in mente – cioè avresti bisogno di sperimentare, assicurati che i record Db sembrino ottimali.

btw. puoi usarlo in questo modo se non lo sapessi, hai dimenticato di postare che …

 var query1 = db.Documents.OfType().ToList(); var query2 = db.Documents.OfType().ToList(); var query3 = db.Documents.OfType().ToList(); var query4 = db.Documents.OfType().ToList(); var query5 = db.Documents.OfType().ToList(); var query6 = db.Documents.OfType().ToList(); 

(provalo per vedere come funziona)