Il presente articolo è stato tradotto automaticamente.

Concetti sui dati

Anteprima delle funzionalità “code-first”, ObjectSet e DbContext di Entity Framework

Julie Lerman

Mentre l'Entity Framework (EF) 4 era ancora in versione beta, il team di sviluppo ha iniziato a lavorare su un altro modo per utilizzarlo. Avevamo database - primo metodo di creazione di un modello (dalla decodificazione un database in un Entity Data Model) e il nuovo modello EF 4 - prima caratteristica (definire un Entity Data Model, quindi creare il database da esso). Inoltre, il team decise di creare un elemento denominato “ codice innanzitutto. ”

Con il codice prima iniziare con il codice, non il database e non al modello. Infatti, con il codice prima è Nessun modello visivo e non XML che descrive tale modello. È sufficiente creare le classi per il dominio applicazione e codice innanzitutto consentirà loro di partecipare al EF. È possibile utilizzare un contesto, scrivere ed eseguire LINQ alle entità query e sfruttare EF rilevamento delle modifiche. Ma non è necessario gestire un modello in una finestra di progettazione. Quando si non creare applicazioni altamente progettate, può quasi dimentichi che il EF è anche presente gestisce tutte le interazioni di database e il rilevamento delle modifiche per l'utente.

Lo sviluppo basato su dominio (ggg) ventole sembrano bello innanzitutto il codice. In realtà, era numerosi gurus ggg che hanno contribuito a team EF comprendere quale codice può eseguire per i programmatori DDD. Estrarre post di blog ’ Danny Simmons su Data Programmability Advisory consiglio per ulteriori informazioni su tale ( blogs.msdn.com/b/dsimmons/archive/2008/06/03/dp-advisory-council.aspx ).

Ma il codice non prima era pronto per l'inclusione in 4 di Microsoft .NET Framework e Visual Studio 2010. In realtà è ancora in evoluzione e Microsoft fornisce agli sviluppatori l'accesso a bit per giocare con e fornire commenti e suggerimenti tramite Entity Framework funzionalità CTP (EF funzione CTP). Il quarto iterazione di questa anteprima di tecnologia comunità (CTP4) è stato rilasciato nel mid luglio 2010. Le modifiche in questa iterazione sono significative.

Oltre a includere l'assembly prima del codice nel CTP4, Microsoft ha lavorato su alcuni nuovi alcune idee per la successiva iterazione del EF. Quelli sono inoltre inclusi in CTP4 che persone di riprodurre tali e, ancora una volta, fornire commenti e suggerimenti. Ancora più importante, codice innanzitutto sfrutta alcune delle nuove funzionalità.

È possibile trovare numerose procedure dettagliate su questa CTP nei post di blog dal team EF ( tinyurl.com/297xm3j ), Scott Guthrie (tinyurl.com/29r3qkb ) e Scott Hanselman (tinyurl.com/253dl2g ).

In questo articolo, si desidera concentrare l'attenzione su alcune delle caratteristiche particolari e i miglioramenti apportati al CTP4 che hanno generato una quantità incredibile di avrai intorno al EF poiché semplificano lo sviluppo di applicazioni di EF — e .NET Framework in generale, così drasticamente.

Miglioramenti di base API

Uno dei miglioramenti importanti che la CTP4 aggiunge al runtime EF è una versione semplificata di due classi di motore, ObjectContext e ObjectSet. ObjectContext consente di interrogazione, rilevamento delle modifiche e salvare il database. ObjectSet incapsula insiemi di oggetti simili.

Le nuove classi DbContext e DbSet, le stesse funzioni essenziali, ma non espongono l'insieme di funzionalità completa di ObjectContext e ObjectSet. Non ogni scenario di codifica richiede l'accesso a tutte le funzionalità delle classi più affidabile. DbContext e DbSet non sono derivati da ObjectContext e ObjectSet ma DbContext fornisce un facile accesso alla versione completa tramite una proprietà: DbContext.ObjectContext.

Nozioni di base ObjectSet e DbSet semplificato

Un ObjectSet è una rappresentazione simile a insieme generica di un insieme di tipi di entità. Ad esempio, avere un ObjectSet <Customer>denominato Customers che è una proprietà di una classe di contesto. LINQ to Entities query scritte contro ObjectSets. Ecco una query ObjectSet Customers:

from customer in context.Customers 
where customer.LastName=="Lerman" 
select customer

ObjectSet ha un costruttore interno e non dispone di un costruttore senza parametri. Consente di creare un ObjectSet avviene tramite il metodo ObjectContext.CreateObjectSet. In una classe di contesto tipico, la proprietà Customers deve essere definita come:

public ObjectSet< Customer> Customers {
  get { 
    return _ customers??
(_customers = 
      CreateObjectSet< Customer >(" Customers"));
  }
}

private ObjectSet< Customer > _ customers;

Ora è possibile scrivere la query clienti e gestire set di aggiunta, il collegamento e l'eliminazione di oggetti, se necessario.

DbSet è molto più semplice da utilizzare. Non è pubblicamente constructible DbSet, simile a ObjectSet, ma consente di creare automaticamente DbSets e assegnarli a qualsiasi proprietà (con Setter pubblica) si dichiara sul DbContext derivata.

I metodi di raccolta ObjectSet sono destinati terminologia EF — AddObject, Attach e DeleteObject:

context.Customers.AddObject(myCust)

DbSet utilizza semplicemente aggiunta, collega e rimozione, che è più in linea con altri nomi di metodo insieme, pertanto non è necessario dedicare tempo scoprire “ come dire che in EF, ” nel modo seguente:

context.Customers.Add(MyCust)

L'utilizzo del metodo Remove anziché DeleteObject inoltre descritte più chiaramente il metodo sta eseguendo. Rimuove un elemento da un insieme. DeleteObject suggerisce che i dati verranno eliminati dal database, ha generato confusione per molti sviluppatori.

La funzionalità Preferiti di DbSet è di gran lunga che esso consente di utilizzare più facilmente i tipi derivati. ObjectSet contiene tipi di base e tutti i tipi che ereditano da esso. Se si dispone di un'entità cliente che deriva da essa, ogni volta che si desidera lavorare con i clienti e contatti, un'entità di base, sarà necessario avviare con ObjectSet contatti. Per eseguire la query per i clienti, ad esempio, scrivere context.Contacts.OfType <Customer>. Non è solo confusione, che anche indubbiamente non è facilmente individuabile. DbSet consente di includere i tipi derivati, a questo punto è possibile creare una proprietà Customers che restituisce DbSet <Customer>e consente l'interazione con cui direttamente anziché attraverso l'insieme di contatti.

DbContext, ovvero un contesto semplificato

DbContext espone le funzionalità più comuni di ObjectContext e fornisce alcuni quelle aggiuntive sono davvero utili. Due funzionalità che preferisco finora di DbContext sono la proprietà di insieme generica e il metodo OnModelCreating.

Tutti questi ObjectSets ho definito finora sono proprietà esplicita di un'istanza di ObjectContext. Si supponga ad esempio di che disporre di un modello denominato PatientHistory contenente tre entità: Paziente, indirizzi e OfficeVisit. È necessario che una classe PatientHistoryEntities, eredita ObjectContext. Questa classe contiene una proprietà di pazienti è un ObjectSet <patient>nonché una proprietà indirizzi e una proprietà OfficeVisits. Se si desidera scrivere codice dinamico utilizzando i generics, è necessario chiamare context.CreateObjectSet <T>dove T è uno dei tipi di entità. Anche questa è semplicemente non rilevabile.

DbContext dispone di un metodo più semplice denominato set consente di chiamare semplicemente context.Set <T> restituirà un DbSet <T>. Solo potrebbe apparire come 12 meno lettere, ma per il cervello codifica utilizzando la proprietà ritiene a destra, mentre non chiama un metodo factory. È anche possibile utilizzare entità derivate con questa proprietà.

Un altro membro DbContext è OnModelCreating, ovvero innanzitutto utile nel codice. Eventuali configurazioni aggiuntive da applicare al modello di dominio possono essere definiti in OnModelCreating prima di EF genera i metadati in memoria basato sulle classi di dominio. Questo è un grande miglioramento rispetto alle versioni precedenti del codice prima. Si vedrà ulteriori informazioni ulteriori su.

Codice ottiene innanzitutto efficiente e più semplice

Codice innanzitutto innanzitutto presentato agli sviluppatori come parte del CTP1 Feature EF nel giugno 2009 con il nome “ solo codice. ” La premessa base dietro questa variazione dell'utilizzo di EF era che gli sviluppatori desiderano semplicemente definire delle classi di dominio e di non preoccuparsi con un modello fisico. Tuttavia il runtime EF dipende da XML del modello di forzare il modello di query in query di database e poi di nuovo i risultati della query dal database in oggetti descritto dal modello. Senza che i metadati del EF non proprio processo. Ma non sono necessario che i metadati in un file fisico. Il EF legge i file XML in una sola volta durante il processo di applicazione, crea oggetti metadati fortemente tipizzato basati su XML che e sono tutti di tale interazione con i dati XML in memoria.

Codice crea innanzitutto gli oggetti nella memoria metadati, troppo. Tuttavia, anziché creare, leggendo i file XML, deduce i metadati dalle classi di dominio (vedere di Figura 1). Utilizza la convenzione per eseguire questa operazione e quindi fornisce un mezzo mediante il quale è possibile aggiungere ulteriori configurazioni per ottimizzare ulteriormente il modello.

Figura 1 codice compila prima i metadati del modello dati entità in fase di esecuzione

Un altro processo importante del codice viene innanzitutto utilizzare i metadati per creare uno schema di database e anche il database stesso. Codice prima ha fornito queste funzionalità dopo la prima versione pubblica.

Ecco un esempio di cui occorre una configurazione per superare alcune supposizioni non validi. Dispone di una classe denominata ConferenceTrack con una proprietà identity denominata TrackId. Convenzione di codice prima di cercare “ ID ” o nome di classe + “ ID ” come proprietà di identità da utilizzare per EntityKey di un'entità e chiave primaria di una tabella di database. Ma TrackId non rientra in questo modello, in modo da indicare il EF che questa è la chiave di identità.

La nuova classe ModelBuilder prima codice genera il modello in memoria in base alle classi descritte in precedenza. È possibile definire ulteriormente le configurazioni utilizzando ModelBuilder. È possibile specificare che l'entità ConferenceTrack deve utilizzare la proprietà TrackId come chiave con la seguente configurazione ModelBuilder:

modelBuilder.Entity<ConferenceTrack>().HasKey(
  ct => ct.TrackId);

ModelBuilder avrà ora in considerazione le informazioni creando il modello in memoria e utilizza lo schema di database.

Applicare configurazioni più logico

Si tratta di DbContext.OnModelCreating entra in così bene. È possibile inserire le configurazioni in questo metodo, in modo che potrà essere applicati come modello da creare, la DbContext:

protected override void OnModelCreating(
  ModelBuilder modelBuilder) { 
  modelBuilder.Entity<ConferenceTrack>().HasKey(
    ct => ct.TrackId); 
}

Un'altra nuova funzionalità aggiunte nel CTP4 è un modo alternativo per applicare configurazioni tramite gli attributi delle classi. Questa tecnica è denominata dati annotazioni. È possibile ottenere la stessa configurazione applicando l'annotazione chiave direttamente alla proprietà TrackId nella classe ConferenceTrack:

[Key] 
public int TrackId { get; set; }

Certamente più semplice, tuttavia le preferenze personali sono utilizzare le configurazioni a livello di programmazione in modo che le classi non dispongono di alcuna conoscenza EF specifiche in essi.

Questo approccio significa anche DbContext occuperà di caching del modello per la costruzione di un'ulteriore DbContexts non comportano costi di individuazione del modello nuovamente.

Relazioni Get Easier

Uno dei miglioramenti più importanti al codice viene innanzitutto è molto più efficiente su presupposizioni dalle classi. Sebbene esistano numerosi miglioramenti per queste convenzioni, trovare le convenzioni di relazione avanzati hanno interessato il mio codice più.

Anche se le relazioni sono definite nelle classi, nella CTP precedente era necessario fornire informazioni di configurazione per definire le relazioni nel modello. Inoltre, le configurazioni erano abbastanza né logico. Ora codice prima possibile interpreta correttamente lo scopo della maggior parte delle relazioni definite nelle classi. Nei casi in cui è necessario modificare il modello con alcune configurazioni, la sintassi è molto semplice.

Le classi di dominio hanno un numero di relazioni definite tramite proprietà. ConferenceTrack ha, ad esempio, questa relazione uno-a-molti:

public ICollection<Session> Sessions { get; set; }

Sessione con la relazione di conversare nonché molti a molti:

public ConferenceTrack ConferenceTrack { get; set; }
public ICollection<Speaker> Speakers { get; set; }

Utilizzando le classi e una singola configurazione (per definire il TrackId come chiave per le conferenze), il Generatore di modelli creati nel database con tutte le relazioni e inheritances illustrato in di Figura 2.

Figura 2 di struttura dei database creati da modelli predefiniti

Si noti la tabella Sessions_Speakers creata per le relazioni molti a molti. Il dominio dispone di una classe workshop che eredita dalla sessione. Per impostazione predefinita, codice presuppone innanzitutto l'ereditarietà tabella per gerarchia, pertanto creata una colonna discriminatore nella tabella Sessions. È possibile utilizzare una configurazione per modificare il suo nome IsWorkshop o anche per specificare che è necessario creare una tabella per ogni tipo di ereditarietà.

Pianificazione ahead di queste nuove funzionalità

Queste interessanti nuove funzionalità che hai accesso anticipata in CTP4 potrebbe essere una fonte di frustrazione per gli sviluppatori che sono dire “ anche se si desidera ora! ” È vero che è semplicemente un'anteprima e non può mettere in produzione oggi ma certamente giocare con questi bit se possibile e fornire commenti e suggerimenti al team EF per renderla ancora migliore. È possibile iniziare la pianificazione per il codice verrà utilizzata prima e altre nuove EF funzionalità nelle applicazioni future.

Julie Lerman è un Microsoft MVP, mentore di .NET e consulente che vive in Colline Vermont. È possibile trovare la sua presentazione sull'accesso ai dati e altri argomenti relativi a Microsoft .NET in gruppi di utenti e conferenze in tutto il mondo. Blog di Lerman all' thedatafarm.com/blog ed è l'autore del libro altamente popolarissimo “ Programming Entity Framework ” (O’Reilly Media, 2009). Follow her on Twitter.com: julielerman.

Grazie all'esperto di tecnica seguente per la revisione di questo articolo: Rowan Miller