Il presente articolo è stato tradotto automaticamente.
Concetti sui dati
Anteprima di Entity Framework 7
.jpg)
Lo sviluppo della prossima versione di Entity Framework è in corso. Ho ottenuto la mia prima panoramica di ciò che il team EF stava modificando al TechEd North America 2014, quando Rowan di Program Manager Miller parlato gli obiettivi per Entity Framework 7 (EF7) e illustrati alcuni bit molto precoce.
Che è stato cinque mesi fa durante la scrittura di questo articolo, e anche se EF7 è ancora un valore alfa anticipato, è già più un. In questa colonna che si desidera informare l'utente di i EF7 che consentiranno agli sviluppatori, alla base delle decisioni vengano effettuati su EF7 e il significato di questa versione per le applicazioni esistenti che utilizzano EF6 o precedenti. Verrà inoltre fornita che consultare quale parte del codice sarà simile.
Open Source, ma ora attiva GitHub
La prima cosa da sapere sulla EF7 è che, come EF6, è open source. Ma, anziché in fase di sviluppo in CodePlex, EF7 è su GitHub, insieme al resto della prossima versione di ASP.NET. L'URL per lo sviluppo di EF7 è github.com/aspnet/EntityFramework. Come con EF6, potrai vedere i dettagli di EF7 evoluzioni. È possibile esplorare il codice sorgente, nonché dello stato di avanzamento tramite succursali e commit, seguire le discussioni, generare problemi, l'origine di fork e inviare richieste di pull per il team esaminare e convalidare potenzialmente alla base di codice.
EF6 Non verrà mantenuto ogni volta che al più presto
Don' t paura, si non essere costretti a spostarsi EF7. Pensare al DataReader e DataSet di ADO.NET . Analogamente a Web Form di ASP.NET , che sono ancora supportate e persino approfittando modifiche occasionali, ADO.NET fa ancora parte di Microsoft.NET Framework, anche se EF è stata la tecnologia di accesso ai dati primari per .NET per molti anni. Non molto è accaduto per migliorare tali tecnologie, ma sono ancora presenti e ancora supporto parecchio codice legacy (fiore incluso). Uno dei grandi vantaggi in che ef6 è per le altre tecnologie è che è open source, anche se il team di Microsoft apporteranno grande investimenti in EF6, la Comunità ancora essere in grado di. E il team EF si impegna a EF6. Continueranno apportare modifiche specifiche, strettamente controllare richieste pull e aggiornare EF6. Anche se essi sono stato in corso del EF7 per una buona parte del 2014, EF6 è stato aggiornato. Versione 6.1.0 è stato rilasciato nel febbraio 2014; 6.1.1 nel giugno 2014; e sto scrivendo questo articolo, 6.1.2 è nella versione beta, di prossima uscita. Si è stato originariamente interessato, ma non è più mi preoccupa è, come la possibilità di mantenere le applicazioni meno recenti verranno. Gli unici che preoccupare sono le applicazioni meno recenti che EF con di 3.5 di.NET Framework, ObjectContext e altro ancora. Ma se non è stato aggiornato delle applicazioni per sfruttare tutti i miglioramenti a EF grandi nel corso degli anni, non è necessario preoccuparsi troppo EF7, comunque. È inoltre possibile trovare tutti i pacchetti precedenti per EF su NuGet, tutti a risalire al EF 4.1.10311.
EF7: Breve elenco
Ecco la panoramica delle novità interessante in EF7:
- Supporto per gli archivi di dati non relazionali e dati in memoria anche per il test.
- Supporto per computer e dispositivi che non utilizzano il.NET Framework completo. Ciò significa che è possibile utilizzare EF7 nelle applicazioni Windows Phone e archivio di Windows, nonché computer Linux e Macintosh che eseguono Mono.
- Supporto per molte funzionalità che gli sviluppatori hanno richiesto ma Impossibile ottenere la base di codice esistente.
- Continua il supporto per le applicazioni che utilizzano il.NET Framework completo, ad esempio Windows Presentation Foundation e altre applicazioni client.
- EF7 verranno distribuiti nello stesso modo come ASP.NET 5 e può essere utilizzato con applicazioni ASP.NET 5.
Conoscere la codifica di Base di superficie, il nuovo codice
Ogni versione di EF si è evoluto il framework, aggiunta di nuove funzionalità e ottimizzazione delle prestazioni e le API. Come ho scritto sulla prima in questa colonna e in un articolo introduttivo nel numero di dicembre 2013, "Entity Framework 6: L'edizione esperto"(bit.ly/1cwjyCD), la versione più recente portate EF a un nuovo livello, offrendo il framework molti degli utenti funzionalità hanno richiesto lungo il percorso, ad esempio l'esecuzione di database asincrone, toccando nella pipeline di query, personalizzazione convenzioni Code First e pertanto molto altro ancora. È visualizzare gran parte all'interno di queste funzionalità nel mio corso Pluralsight, "Entity Framework 6, edizione esperto: Novità di EF6 "(PS/bit.ly-EF6).
Si sono verificati gli sviluppatori di funzionalità ancora più chiesta per EF da Microsoft era felici di poter implementare, ma il codice di 10-e anni EF base si basa su, ovvero con una dipendenza continuata su ObjectContext e meno flessibili i modelli di codifica, ovvero ha impedito il team possa raggiungere questo livello di funzionalità. Una decisione difficile, che certamente molti di voi hanno dovuto affrontare con il proprio software legacy, ovvero è stata effettuata per ricostruire Entity Framework partendo da zero.
EF7 non è creare un nuovo framework per l'accesso ai dati. Compilazione, invece, una nuova e più sostenibile base su cui supportano non soltanto le funzionalità e flusso di lavoro che dipendeva da anni con EF, ma anche uno che consentirà a molto di più. Il team impegnati se deve essere il successivo EF o dati nuove tecnologia di accesso. In un punto, anche contestato se è "EF Light". Le funzionalità principali di EF sono ancora presente, ma dopo molta considerazione, accetto che è opportuno considerare questa come la prossima versione di Entity Framework. È possibile leggere ulteriori informazioni, vedere il blog del team registrano, "EF7-v1 o v7?" (bit.ly/1EFEdRH).
Riduzione del peso alcuni Legacy, mantenendo le parti buone
Inoltre esiste ancora notizie su EF7 è preoccupante per alcuni sviluppatori. Mentre i più comuni EF classi, modelli e flussi di lavoro rimarrà intatti, alcuni dei membri meno utilizzata verrà lasciato. Ma, Niente panico. Più avanti parlerò su questo argomento.
Consentendo agli sviluppatori di continuare a utilizzare delle corrispondenze e anche riuscire a importi buona porta del codice esistente per EF7 è stato un obiettivo fondamentale. Si continuerà a utilizzare DbContext, elemento DbSet, LINQ query, SaveChanges e molti dei mezzi di interazione che sono stati parte di EF per molto tempo.
Ecco una classe di DbContext che è definita in EF7:
public class BreweryContext : DbContext {
public DbSet<Brewery> Breweries { get; set; }
public DbSet<Beer> Beers { get; set; }
}
Ed ecco un semplice aggiornamento in EF7 è la stessa EF6. Si utilizza un salvataggio sincrono, ma tutti i metodi asincroni sono presenti, nonché:
public void StoreBeers(List<Beer> beers) {
using (var context = new BreweryContext()) {
context.Beers.AddRange(beers);
context.SaveChanges();
}
}
E una semplice query:
using (var context = new BreweryContext()) {
return context.Breweries.Where(b=>b.Location.Contains("Vermont"));
}
Si sta utilizzando la versione di EF7 in pacchetti con versione beta2-11616. EF7 non è realmente beta in questo momento, ma "beta2" è correlata a una decisione di denominazione dei pacchetti di NuGet. Dal momento della pubblicazione di questo articolo, EF7 verrà si sono evolute, inoltre, questa operazione, valutare questo aspetto un aspetto, non una promessa.
Ho comunque avere un DbContext e definire DbSets, come ho fatto sempre. OnModelCreating è ancora presente, anche se non lo utilizzerò qui.
EF4.1 è stato introdotto l'API DbContext, che è stato molto più incentrate sull'utilizzo tipico di EF. Trova di sotto, ancora facendo affidamento su ObjectContext originale che consente l'interazione di database, le transazioni vengono gestite e tiene traccia dello stato di oggetti. Da allora, DbContext è diventata la classe predefinita da utilizzare e sarebbe Dissolvi verso il basso per le API di livello inferiore se si desidera realizzare un'interazione con l'ObjectContext rara. EF7 descrive brevemente l'ObjectContext obese; rimane solo il DbContext. Ma alcune di queste attività per che utilizzavano l'ObjectContext sarà ancora accessibile.
Alcuni dei mapping molto complesse che sono difficili da supportare e non utilizzati comunemente si verificheranno con EF7. Viene visualizzato il post di blog citati in precedenza, ", ad esempio, si potrebbe avere un hier ereditarietàarchy che combinati i mapping di tabella per gerarchia, funzionalità e TPC, nonché la divisione di entità, tutte nella stessa gerarchia." Se si è mai tentato di utilizzare direttamente l'API MetadataWorkspace ed eseguire stoccaggio disperazione, sai che è una potenza intricata e complessa, utile per la possibilità di supportare questo tipo di flessibilità. Ma tale complessità ha impedito il team di essere in grado di supportare altri scenari per il quale gli utenti hanno richiesto. Semplificando così le possibilità di mapping, l'API MetadataWorkspace diventato più semplice e più flessibile. È possibile ottenere facilmente ai metadati lo schema del modello dall'API DbContext in EF7, che offre una funzionalità di basso livello per eseguire tecniche avanzate senza che dispone di basso livello ObjectContext.
Eliminazione EDMX, ma che Database primo Will continuare
Entity Framework attualmente dispone di due modi per descrivere un modello. Una viene utilizzato un EDMX nella finestra di progettazione; l'altro riguarda le classi, una DbContext e mapping utilizzate dalle API primo codice. Se si utilizza il EDMX e progettazione, in fase di esecuzione EF crea un modello in memoria da XML dietro il EDMX. Se si sceglie il primo codice percorso, EF crea lo stesso modello in memoria leggendo il mapping che è fornito, DbContext e classi. Da quel momento, EF funziona allo stesso, indipendentemente da come descritto il modello. Si noti che con il flusso di lavoro EDMX o di progettazione, è inoltre possibile ottenere classi POCO e un DbContext da utilizzare nel codice. Ma poiché il EDMX è presente, non vengono utilizzati per creare tale modello in memoria. È importante comprendere come si legge la frase successiva: EF7 non supporta il modello EDMX basato su finestra di progettazione. Non avrà la possibilità di leggere i dati XML EDMX in fase di esecuzione per creare il modello in memoria. Verrà utilizzato solo il primo codice del flusso di lavoro.
Quando il team discusso su questo, causato panico tra gli sviluppatori. In parte questo era dovuto al fatto che molti ancora non si rende conto che è possibile decodificare un database di classi POCO, DbContext e mapping. In altre parole, è possibile avviare un database per ottenere un modello Code First. Questo è stato possibile poiché la versione Beta di EF Power Tools primo rilascio nel 2011 anticipata. È supportato dalla finestra di progettazione EF6.1 e indubbiamente sarà supportato per EF7. Ho detto molte volte che il moniker "Code First" è un po' confusione e fuorvianti. È stato originalmente chiamato "Solo codice", ma il nome è stato cambiato in "Code First" per creare una corrispondenza interessante con "Database First" e "Model innanzitutto".
Pertanto non è necessario che la finestra di progettazione o un EDMX iniziare con un database esistente.
Ma cosa succede se si dispongono di modelli EDMX esistenti e non desidera perdere la possibilità di utilizzare una finestra di progettazione? Sono disponibili strumenti di progettazione di terze parti che supportano Entity Framework, ad esempio LLBLGen Pro progettazione, che supporta già EF Code First (bit.ly/11OLlN2) e lo sviluppatore di entità Devart (bit.ly/1yHWbB2). Cercare di tali strumenti e probabilmente altre potenzialmente fornire supporto di progettazione per EF7.
È ancora un altro percorso da tenere presenti: utilizzo di EF6!
Sistemi operativi, ulteriori dispositivi e design più compatto
Inoltre, Microsoft strove semplificare la distribuzione delle API EF. La cartella del pacchetto NuGet per EF6.1.1 è di circa 22MB. Questo include un assembly 5.5MB per .NET Framework 4.5 e un altro nel caso in cui si utilizza.NET Framework 4. Con EF7, sono disponibili un numero di DLL di dimensioni ridotte. È possibile combinare solo le DLL necessarie per supportare il flusso di lavoro. Ad esempio, se la destinazione SQL Server, si utilizzerà un core EntityFramework, una DLL per SQL Server e un altro con le API comuni per archivi dati relazionali. Se si desidera utilizzare le migrazioni, che è un assembly separato, che è possibile ignorare. In caso contrario, è possibile creare ed eseguire migrazioni dalla Console di Gestione pacchetti . Esiste un'API per i comandi. Utilizzando Gestione pacchetto NuGet, i pacchetti corretti verranno identificati e scaricati tramite le relative dipendenze, quindi non è necessario preoccuparsi troppo i dettagli.
Questa operazione è di ridurre al minimo l'ingombro EF7 sul computer dell'utente finale o il dispositivo, è particolarmente importante nei dispositivi. ASP.NET consentirà di questa route. Entrambe queste tecnologie scartano dipendenza dal completa di.NET Framework. Al contrario, verrà distribuito solo le DLL necessari per svolgere le attività di una determinata applicazione. Ciò significa che la versione già semplificata di .NET utilizzata da applicazioni Windows Phone e Windows Store sarà in grado di utilizzare EF7.
Significa anche che i sistemi operativi come OS X e Linux che utilizzano Mono anziché completa di.NET Framework saranno inoltre in grado di supportare sul lato client Entity Framework.
Oltre relazionale
Quando è stato introdotto Entity Framework , Microsoft aveva una visione di esso viene utilizzato per una vasta gamma di archivi di dati, anche se il primo passaggio incentrata su database relazionali. Database non relazionali esistenti in quel momento, ma non sono stati ampiamente utilizzati, a differenza del database NoSQL, soprattutto i database di documenti, che vengono così diffusi oggi.
Mentre EF è un relazionale Mapper ORM (Object), gli sviluppatori che utilizzano tale da essere in grado di utilizzare gli stessi costrutti di interagire con i database non relazionali. EF7 un alto livello di supporto per questo, ma tenere presente in realtà indica il livello elevato. Esistono grandi differenze tra database relazionali e di database non relazionali ed EF non consentirà a qualsiasi tentativo di mascherare tali differenze. Ma per una query di base e gli aggiornamenti, sarà possibile utilizzare i modelli con cui ha già familiarità.
Figura 1 viene illustrato il codice da un'applicazione di esempio destinato a Microsoft Azure Storage di tabella, che è un database non relazionale del documento. L'esempio viene fornito da Program Manager EF Rowan Miller in github.com/rowanmiller/Demo-EF7. Si noti che l'esempio viene eseguito con la versione delle compilazioni notturne alfa EF7 11514.
DbContext figura 1 definito per l'utilizzo di tabelle di Azure Storage
public class WarrantyContext : DbContext
{
public DbSet<WarrantyInfo> Warranties { get; set; }
protected override void OnConfiguring(DbContextOptions options) {
var connection =
ConfigurationManager.ConnectionStrings["WarrantyConnection"]
.ConnectionString;
options.UseAzureTableStorage(connection);
}
protected override void OnModelCreating(ModelBuilder builder) {
builder.Entity<WarrantyInfo>()
.ForAzureTableStorage()
.PartitionAndRowKey(w => w.BikeModelNo, w => w.BikeSerialNo);
}
}
Il metodo OnConfiguring è una novità. È un modo di influire sul modo EF configura il DbContext in fase di esecuzione, piuttosto come si può fare oggi con la classe DbConfiguration. Si noti il generatore.Metodo di estensione UseAzureTableStorage, che esiste perché è stato installato anche il pacchetto di EntityFramework.AzureTableStorage nel progetto.
EF7 utilizza questo modello per i vari provider. Ecco un metodo di OnConfiguring in una classe DbContext all'interno di un progetto destinato a SQLite:
protected override void OnConfiguring(DbContextOptions builder) {
string dir = ApplicationData.Current.LocalFolder.Path;
string connection = "Filename=" + Path.Combine(dir, "VermontBrewery.db");
builder.UseSQLite(connection);
}
Questo progetto è il pacchetto EntityFramework.SQLite installato, questa operazione ora ho invece il metodo di estensione UseSQLite.
Nella classe WarrantyContext in Figura 1, è possibile visualizzare l'override OnModelCreating familiare per DbContext e in tale posizione si eseguono alcuni mapping speciale. Anche in questo caso ho metodi forniti dal pacchetto EntityFramework.AzureTableStorage NuGet. Viene visualizzato scegliere i pacchetti da in base alle caratteristiche necessarie. Tabella di archiviazione Azure si basa su una coppia chiave-valore per l'identità univoca e supporta il partizionamento delle tabelle. Per recuperare o memorizzare i dati, è fondamentale sapere quali sono i valori da utilizzare per la PartitionKey e la RowKey, in modo che l'API fornisce un metodo, ovvero PartitionAndRowKey, che consente di eseguire il mapping delle proprietà per le chiavi appropriate. Il concetto non è diverso da come era possibile utilizzare l'API intuitiva o le annotazioni dati per specificare la proprietà che viene mappato alla chiave primaria del database relazionale.
Grazie a questo mapping, è possibile scrivere una query LINQ familiare per recuperare alcuni dati:
var warranty = _context.Warranties
.Where(w =>
w.BikeModelNo == modelNo
&& w.BikeSerialNo == serialNo)
.SingleOrDefault();
Quindi vengono visualizzati una tipica query LINQ , ma è in esecuzione nell'archivio dati di archiviazione di tabelle di Azure, così come è possibile fare oggi con un database relazionale.
In questa demo stessa consente inoltre di aggiornare gli oggetti di garanzia; Crea e inserisce nuove utilizzando DbSet.Add; e utilizza DbContext.SaveChanges per mantenere tutto l'archivio di dati nello stesso modo odierno con EF6 e ha svolto in tutta la cronologia di EF.
Inoltre interessante da considerare è come Entity Framework ha sempre supportato un insieme di funzionalità canonico per il mapping su database relazionali, ma lasciata al provider del database per specificare come quelli convertirebbe al database destinazione. EF7 con un insieme ad alto livello di funzionalità canonico che può essere compresa dagli archivi dati relazionali e non relazionali. Esiste anche un livello inferiore insieme di funzionalità che lo stato attivo su database relazionali, e è incapsulati nell'assembly EntityFramework.Relational. Tutti i provider di database relazionale verrà dipendono da quelle e come oggi, la gestione specifica di interazione con il database viene memorizzato nel proprio provider di API, come EntityFramework.SQLite utilizzato in precedenza. Sono disponibili metodi di estensione in provider che girano all'esterno di un metodo AsRelational, ovvero nell'API relazionale. È un metodo di estensione di DbContext.
Esiste anche un provider dell'archivio dati in memoria, ovvero per gli unit test quando si desidera evitare un'interazione di database che potrebbe essere coinvolti nella logica che si sta testando. In genere in questi scenari utilizzare dati falsi o Framework di simulazione di rappresentare l'interazione con il database.
Se è stato impostato su un test per eseguire una query o aggiornare il database, è necessario un codice per creare un'istanza del database, ad esempio:
using (var context = new BreweryContext()) {
// Perform some action against the context
}
È possibile passare facilmente a un archivio in memoria installando il entityframework.Pacchetto InMemory al progetto di test, definendo un DbContextOption per InMemoryStore e quindi specificando che il contesto deve utilizzare tale opzione. Anche questa è possibile grazie ai metodi di estensione forniti da questa API:
var options = new DbContextOptions().UseInMemoryStore();
using (var context = new BreweryContext(options)){
// Perform some action against the context
}
Ulteriori funzionalità, ulteriori funzionalità, molto più flessibile
Potete vedere i vantaggi del nuovo codice di base nella flessibilità forniscono i metodi di estensione e la possibilità di influenzare la pipeline Entity Framework con la OnConfiguring dell'overload. Sono disponibili punti di estendibilità per tutta la nuova base di codice, non solo per la modifica di EF7, ma anche per rendere più semplice per è possibile collegarsi a una propria logica per EF7.
Il nuovo codice di base base consente al team EF di risolvere alcuni problemi sempre se. Ad esempio, la versione che utilizzi già dispone di supporto per l'aggiornamento in blocco, il valore predefinito per i database relazionali. Ho ho avviato con il codice che consente di utilizzare personale inline metodi nelle query LINQ senza ricevere il temutoEntity Framework non è possibile tradurre questo metodo in SQL." Al contrario, EF e i provider sono in grado di analizzare quale parte della query diventerà SQL e che verrà ottenere eseguito localmente sul client. Sono certo che sarà protezione da indicazioni e per evitare alcuni potenziali problemi di prestazioni per una particolare funzionalità.
Il team è stato in grado di aggiungere la funzionalità di chiavi esterne univoco richiesto long per i modelli. Inoltre che vogliono strettamente a fornire supporto per le funzioni con valori di tabella e pulito modi per gestire i dati disconnessi, ovvero un avvenimento che ho alla per molti anni con Entity Framework. È un problema comune con le applicazioni disconnesse, non solo quando è coinvolto Entity Framework , e non è facile creare algoritmi in grado di funzionare in modo coerente in ogni scenario. Un nuovo approccio non è necessario, certezza.
È molto più accogliere con entusiasmo con EF7. Consiglio vivamente di attenzione il post sul Blog del Team ADO.NET alla blogs.msdn.com/adonet. Oltre ai post collegati a versioni precedenti, Rowan Miller ha scritto approfondite relative alla decisione per rimuovere il supporto di progettazione presenti EF7; vedere "EF7 - che cos' 'innanzitutto solo codice' significato effettivo" in bit.ly/1sLM3Ur. Tenere d'occhio questo blog, come il progetto GitHub. Wiki su GitHub (bit.ly/1viwqXu) sono disponibili collegamenti a come accedere alle compilazioni notturne; come scaricare, compilare ed eseguire il debug del codice sorgente; alcuni volume contiene alcune e design note riunione. Il team è immediato per il tuo feedback e lieti di ricevere richieste di pull.
Una decisione non sottovalutare
È importante per me scrivere su EF7 per alleviare alcuni timori su una sostanziale modifica e che alcune delle funzionalità EF esistenti che potrebbero essere parte integrante delle applicazioni non è possibile trasformarlo in EF7. Questi timori siano infondati e il team non richiede tali lightly, né si è. Ma che EF6 non si verificheranno e continuerà a svilupparsi con contributi della Comunità è essenziale comprendere. Se si desidera sfruttare il movimento in avanti, è possibile effettuare alcune scelte difficili. Aggiornamento di applicazioni di grandi dimensioni non è semplice ed è opportuno valutare attentamente le opzioni. Forse è possibile suddividere l'applicazione solo alcune parti di beneficiare dei EF7 di riscrittura.
Nuovamente, come scrittura di questo articolo, EF7 è ancora nelle fasi iniziali e non sono certi quanto attraverso di esso verrà al momento è letto questo. Tuttavia, gli origine disponibile corrente e i pacchetti NuGet per esplorare, sperimentare e fornire commenti e suggerimenti. Tenere presente che il team può non sempre mantenere tutti i provider di API (come Redis, SQLite e altri) aggiornato evolversi l'API di base. Secondo il post a bit.ly/1ykagF0, "EF7 - le priorità, lo stato attivo e rilascio iniziale," la prima versione di EF7 sarà incentrata sulla compatibilità con ASP.NET 5. Le versioni successive verranno aggiunti ulteriori funzionalità. Comunque, anche se EF7 non è ancora sufficientemente stabili per iniziare a creare applicazioni con esiste indubbiamente sufficiente vi consentono di avviare la pianificazione.
Julie Lerman è un Microsoft MVP, mentore e consulente .NET che risiede nel Vermont. È possibile trovare la presentazione su dati argomenti other.NET e accesso a gruppi di utenti e conferenze in tutto il mondo. Blog di Mary al thedatafarm.com ed è l'autore di "programmazione Entity Framework" (2010), nonché una codice prima edizione (2011) e un'edizione DbContext (2012), da o ' Reilly Media. È possibile seguirla su Twitter al twitter.com/julielerman e vedere proprio corsi Pluralsight a Juliel.me/PS-video.
Grazie al seguente esperto tecnico di Microsoft per la revisione di questo articolo: Rowan Miller
Questo si basa su una versione alfa di Entity Framework 7. Tutte le informazioni sono soggette a modifiche.