2016-06-14 13 views
15

Ho provato a leggere il msdn article su tipi complessi. Ma non spiega quando usarlo. Inoltre non c'è una spiegazione completa sul web su tipi complessi e quando usarli.Che cos'è un tipo complesso nel framework entità e quando utilizzarlo?

+1

che segue fornisce ulteriori dettagli, anche se non risponde direttamente alla tua domanda - [Associazioni in EF Codice Primo: Parte 2 - tipi complessi] (http: //weblogs.asp.net/manavi/associations-in-ef-4-1-code-first-part-2-complex-types) –

+0

grazie Lo esaminerò –

risposta

23

La lunga spiegazione è nel articolo di MSDN si è collegato ... così si vuole fondamentalmente una spiegazione semplice:

un tipo complesso è un insieme di proprietà che esistono nel proprio oggetto per C#, ma sono mappati a colonne su una tabella già esistente (quella per l'entità che la contiene), invece di avere la propria tabella (che avrebbe bisogno di una chiave, ecc.).

Così Immaginate di voler questa tabella sul database:

Orders 
---------- 
Id (bigint) 
Name (varchar) 
Street (varchar) 
Region (varchar) 
Country (varchar) 

ma vuole questa struttura nel C# entità:

class Order 
{ 
    long Id; 
    string Name; 

    struct Address 
    { 
    string Street; 
    string Region; 
    string Country; 
    } 
} 

Quindi ci Address sarebbe un tipo complesso: non esisterebbe da solo (non ci sarebbe la tabella Addresses) nel database ... esisterebbe solo come una serie di colonne sulla tabella Orders.

Come notato da @HenkHolterman nei commenti, il valore di avere tipi complessi sta avendo un # un'entità singola C che può essere utilizzato come un valore per altre entità che contengono (nel mio esempio, si potrebbe avere un Address in un'entità Supplier , ad esempio, ma verrà mappato come un insieme di colonne nella tabella Suppliers). Rende facile lavorare con i valori nel tipo complesso.

Lo svantaggio è proprio quello: potrebbe essere necessario ripetere i valori di tipo complessi più volte nel database se accade che uno stesso Address (o qualsiasi altro tipo utilizzato) possa essere condiviso tra diverse entità.

Se si sceglie di lavorare con tipi complessi o entità separate dipende da voi e il vostro disegno.

+1

I tuoi commenti sulla tua risposta non hanno senso, assomiglia a @HenkHolterman cancellato i suoi commenti – Thomas

7

Considerate questa classe ContactDetails ad esempio:

public class ContactDetails 
{ 
    public string HomePhone { get; set; } 
    public string MobilePhone { get; set; } 
    public string FaxNumber { get; set; } 
} 

Per impostazione predefinita, EF tratterà ContactDetails come Entity. Ciò significa che, se (ad esempio) si sta avendo una classe Person con una navigazione di proprietà di ContactDetails tipo, EF sarà mappare il rapporto Person.ContactDetails ad una tabella diversa (a causa Entity è qualcosa che sta avendo un identità della sua proprio, quindi altre entità possono riferirsi ad esso - e ciò richiederebbe una tabella diversa in termini relazionali).

Indicando ContactDetails come un complesso tipo invece, EF non sarà più trattarlo come un'entità che richiede un rapporto e invece mapparlo allo stesso tavolo del genitore (contenente) entità (Person nel mio esempio), rendendolo effettivamente un Value Object.