Gennaio 2017
Volume 32 Numero 1
Il presente articolo è stato tradotto automaticamente.
Punti dati - EF Core 1.1: I pezzi forti
Da Julie Lerman
.jpg "Julie Lerman")
Come si scrive in questa colonna (nel novembre 2016), Entity Framework (EF) Core 1.1 è stato appena rilasciato. Tra la 1.0 versione e 1.1, si sono verificati alcuni elementi significativi. In particolare, il 1.0.1 patch fissa alcuni bug di importanza critica che sono stati individuati come 1.0 è stato rilasciato. Per un elenco dettagliato delle correzioni, è possibile leggere le note sulla versione in bit.ly/2fl5xNE. Sebbene la maggior parte di queste correzioni relative a come vengono trasformate le query LINQ to SQL, esistono anche correzioni per il generatore di modelli e la persistenza tramite SaveChanges e migrazioni.
Core Entity Framework 1.1 integra correzioni di bug aggiuntive, molti altri miglioramenti per la modalità di interpretazione delle query LINQ e miglioramenti delle prestazioni di grandi dimensioni. Ma sono disponibili anche nuove funzionalità, ovvero che esisteva in Entity Framework 6 ma non l'aveste apportate a Entity Framework Core 1.0, mantenendo molti sviluppatori anche esaminando il nucleo di Entity Framework e altri che non hanno familiarità. Che desidera eseguire in questo articolo è presente un rapido elenco di queste modifiche e quindi evidenziare alcune delle quali sono di grande interesse all'utente. Verrà inoltre collegamenti a numerose risorse preziose che usare nel mio lavoro richiesto al passo con EF Core evoluzione. Per iniziare, una vasta gamma di queste informazioni è illustrata nella documentazione di (docs.microsoft.com/ef) e i post del blog del team (bit.ly/2ehZBUB).
In particolare, è necessario tenere del blog di Arthur Vickers. Arthur è uno sviluppatore senior che lavora nel team di dall'inizio di POCO in Entity Framework supporta ed è stata strumentale per la modernizzazione di Entity Framework. Ha una grande serie di post su Entity Framework 1.1 Core in blog.oneunicorn.com.
Microsoft prevede di rendere molte funzionalità di Entity Framework 6 Core Entity Framework, ma non tutte. E sono presenti un numero di nuove funzionalità pianificate che nelle versioni future. Attualmente, Entity Framework Core 1.1 si concentra su aggiornamenti, che renderebbero EF Core più soddisfacente per un numero maggiore di sviluppatori. Ecco la più importante di queste funzionalità.
Entity Framework 6 Funzionalità in Entity Framework 1.1
Il metodo DbSet.Find, che è diventato disponibile con l'introduzione dell'API DbContext di Entity Framework 4.1, non sono state inserite nell'elenco di passaggi per la prima iterazione del nucleo di Entity Framework, disturbi molti sviluppatori. Trovare più di un modo pratico per eseguire una query in modo efficiente per un'entità dipende dal valore della chiave. Verifica innanzitutto se tale entità è già in memoria e viene rilevata da Entity Framework. Se l'entità non viene trovato nella cache DbContext, Entity Framework esegue una query FirstOrDefault sul database per recuperare l'entità. Questa era una query SingleOrDefault in Entity Framework 6 e versioni precedenti. Progettazione di ricerca per evitare un viaggio non necessario per il database è anche un miglioramento delle prestazioni. Se si desidera visualizzare la struttura come me, è possibile trovare il codice nella classe EntityFinder su GitHub (bit.ly/2e9V0Uu).
La grande differenza è che trova è ora in un servizio EntityFinder; non è semplicemente un metodo implementato direttamente in una classe DbSet interna come se fosse in Entity Framework 6. Entity Framework principale è costituito da centinaia di servizi per incapsulare attività specifiche. Nella sua demo del video di Channel 9 su Entity Framework Core 1.1 (bit.ly/2fHOCsN), Rowan Miller viene illustrato come utilizzare direttamente i servizi, nonché come sostituirli.
Inoltre sempre parte di Entity Framework principale con l'aggiornamento 1.1 è la funzionalità di Entity Framework 6 detta resilienza della connessione, che fornisce il supporto per gestire facilmente i problemi di connessione temporanei che possono verificarsi quando si utilizza un database remoto, ad esempio Database SQL di Azure. Se si utilizza l'inserimento delle dipendenze principali di ASP.NET, è possibile impostare il metodo di estensione EnableRetryOnFailure del provider di Database SQL in DbContext.OnConfiguring o la chiamata di AddDbcontext in Startup.cs. Chiama EnableRetryOnFailure SqlServerRetryingExecutionStrategy, che eredita da ExecutionStrategy il tipo. È possibile creare e impostare il proprio ExcecutionStrategy e altri provider possibile predefinire configurazioni proprie ExecutionStrategy. Se non avete familiarità con questa funzionalità, è simile a DbExecutionStrategy di Entity Framework 6, trattati in dettaglio nel mio corso Pluralsight ', "Versione Ninja di Entity Framework 6" (bit.ly/PS_EF6).
Entity Framework fornisce tre metodi di caricamento dei dati correlati. Uno, il caricamento, è abilitato per il metodo DbSet.Include per recuperare i grafici dei dati in una singola query. Altri due controlli, al contrario, caricare i dati correlati dopo che gli oggetti principali sono già in memoria mentre DbContext che tiene traccia delle loro è ancora nell'ambito. Il caricamento lazy automaticamente effettua il pull dei dati correlati su richiesta, mentre con il caricamento esplicito è indicare in modo esplicito a caricare i dati correlati a Entity Framework. Includere il primo di questi vengano implementati in Entity Framework Core e disponibile con Entity Framework Core 1.0. Contiene anche alcuni interessanti miglioramenti rispetto alle versioni da Entity Framework 6 e versioni precedenti. Caricamento esplicito con il metodo di caricamento è stato aggiunto in Entity Framework Core 1.1. Il caricamento lazy non è ancora supportato, ma sarà un certo punto.
Rilevamento delle modifiche di DbContext API consentono l'accesso modificare le informazioni di individuazione direttamente, ad esempio ottenere o impostare lo stato di un'entità con la DbContext.Entry(someObject). Metodo di stato. Entity Framework 6 portato controllo aggiuntivo con nuovi metodi come GetDatabaseValues, CurrentValues e OriginalValues. Questi metodi sono ora disponibili in Entity Framework Core 1.1.
Nuove funzionalità di Entity Framework 1.1
Entity Framework Core viene riempita con le funzionalità non disponibili nelle versioni precedenti. Ecco un breve elenco di esempi: invio in batch durante SaveChanges, chiavi esterne univoche, il provider InMemory preziosi per il test, mapping fluent elaborazione e più intelligente e più semplice di query LINQ più intelligenti.
Entity Framework 1.1 introduce alcune nuove funzionalità aggiuntive ed è presente uno in particolare che, come un utente che è un grande fan della progettazione basata su domini, sono piuttosto in, il supporto per le raccolte incapsulate.
Mapping di campi e raccolte incapsulato Code First di Entity Framework ha sempre supportato mapping per le proprietà che dispongono sia un metodo Get e set, anche se il metodo di impostazione è privato. E per gli spostamenti tra raccolta, la proprietà è stato richiesto da ICollection. Se si desidera vincolare come vengono popolati i valori delle proprietà, la possibilità di incapsulare la proprietà è fondamentale, in questo modo è possibile forzare gli utenti che utilizzano la classe per utilizzare un metodo pubblico per assicurarsi che le regole di business per tale proprietà vengono rispettate. Entity Framework 6 e versioni precedenti consentono di incapsulare le proprietà scalari, rendendo il setter privato. Ma non è possibile incapsulare raccolte realmente e impedire a utenti di modificare direttamente la raccolta.
Con Entity Framework 1.1, è possibile ottenere la possibilità di eseguire il mapping direttamente ai campi, nonché per eseguire il mapping alle proprietà IEnumerable. La nuova capacità di eseguire il mapping ai campi, non solo le proprietà, consente di utilizzare un approccio più diretto rispetto a nascondere il setter e supporta anche alcuni altri modi di incapsulare i valori scalari. Di seguito è una proprietà, DueDate, che dispone di un metodo di richiamo ma nessun metodo di impostazione, nel campo, _dueDate, che è collegato alla proprietà:
private DateTime _dueDate;
public DateTime DueDate {
get { return _dueDate;
}
}
L'unico modo per impostare DueDate è chiamando il metodo CalculateDueDate, che consente di modificare il campo:
private void CalculateDueDate() {
_dueDate=Start.AddDays(DaysLoaned);
}
Componenti di base di Entity Framework 1.1 richiede un mapping esplicito in DbContext per segnalare che è possibile utilizzare il campo _dueDate per eseguire il mapping al database, ad esempio durante la restituzione dei risultati di una query a Entity Framework. È necessario utilizzare la proprietà (e facoltativamente HasField) metodi API per specificare che il campo _dueDate è un sostituto per la proprietà DueDate. In questo caso, poiché il nome di campo, _dueDate, seguono una convenzione di Entity Framework, non è necessario utilizzare il metodo HasField, ma ho aggiunto in così è possibile visualizzarlo:
protected override void OnModelCreating(ModelBuilder modelBuilder) {
modelBuilder.Entity<BookLoan>().Property(bl => bl.DueDate)
.HasField(“_dueDate”);
}
Benché sia possibile utilizzare Setter privato prima che fosse disponibile il mapping dei campi, si è verificato alcun modo per incapsulare le raccolte, per impedire a utenti di modificare direttamente una raccolta tramite i metodi di aggiunta o rimozione. Non è una questione di nascondere il setter; gli elementi necessari è quello di nascondere i metodi di raccolta. Un approccio comune in DDD consiste nel rendere la proprietà di un oggetto IEnumerable. Tuttavia, con Entity Framework 6 e versioni precedenti, è possibile mappare solo a una versione di ICollection; ma non è IEnumerable ICollection.
Inizialmente ho esaminato per verificare se è possibile utilizzare la funzionalità di mapping dei campi, ma con Entity Framework 1.1 non è possibile in quanto supporta solo il mapping alle proprietà scalari. Questo è finalizzato a modificare nella prossima versione di Entity Framework Core, che consente il mapping alle proprietà di navigazione. Ma quando evidenziato in questo giorno su Twitter, Arthur Vickers informare l'utente che in realtà è possibile mappare a IEnumerables: qualcosa avevo dimentico in qualche modo sulla base di Entity Framework. Sono ora in grado di incapsulare e proteggere una raccolta completamente, costringendo gli utenti della mia API passare attraverso un metodo per modificare la raccolta. Di seguito è riportato un esempio in cui è possibile aggiungere nuove istanze di BookLoan a un libro, ogni volta che viene concesso in prestito, garantendo che la durata del prestito è inclusa:
private List<BookLoan> _bookLoans;
public IEnumerable<BookLoan> BookLoans {
get { return _bookLoans; }
}
public void BookWasLoaned(int daysLoaned){
_bookLoans.Add(new BookLoan(DateTime.Today, 14));
}
Si tratta di un modello per la realizzazione di incapsulamento sfruttando il mapping di IEnumerable. Ma si consiglia di leggere il post di blog Arthur (bit.ly/2fVzIfN) per ulteriori informazioni, tra cui come eseguire questa operazione senza un campo di backup (in stile campo _bookLoans), per alcuni trucchi e miglioramenti piani di attenzione.
Supporto per funzionalità specifiche del Database Core Entity Framework è progettato per consentire a più facilmente supportano funzionalità specifiche dell'archivio dati. Un esempio è che il provider SQL Server per le principali di Entity Framework supporta le tabelle SQL Server Memory-Optimized per le applicazioni in cui è necessario molto elevata velocità effettiva. Per specificare che un'entità mappata a questo tipo speciale di tabella, il provider SQL Server dispone di un metodo di estensione che è possibile utilizzare quando si configura il modello con l'API Fluent:
modelBuilder.Entity<Book>().ForSqlServerIsMemoryOptimized();
Non solo verrà questo influiscono sul modo in cui prima genera codice di script di creazione tabella, ma anche influirà come Entity Framework genera comandi push dei dati nel database. È possibile visualizzare una dimostrazione interessa di questo nel video di Channel 9 menzionato in precedenza in Rowan Miller demo funzionalità Entity Framework 1.1.
Shay Rojansky, che hanno creato il provider di PostgreSQL per Entity Framework Core, ha scritto un articolo su come Entity Framework Core ha consentito di supportare funzionalità speciali di PosgreSQL quali tipi di matrice. Leggere da bit.ly/2focZKQ.
Semplificano l'accesso ai servizi
Come evidenziato in precedenza con il servizio EntityFinder, Entity Framework principale è costituito da centinaia di servizi. In questo video di Channel 9, Rowan viene illustrato come accedere e utilizzare tali servizi direttamente nel codice. Inoltre, è possibile eseguire l'override di un servizio con il proprio personalizzazione. Entity Framework 1.1 rende più semplice che con un semplice sostituire metodo che può essere utilizzato in OnConfiguring. È possibile sostituire un servizio con un altro che eredita da tale servizio o implementa l'interfaccia stessa. Non esiste alcun particolare elenco di servizi, sono semplicemente delle classi in tutta l'API di EntityFrameworkCore diversi. Un esempio chiaro e semplice consiste nel creare una classe che eredita da un mapper del tipo di database, ad esempio SqlLiteTypeMapper dal provider di Sqlite e aggiungere una nuova regola di mapping dei tipi. Assicurarsi che tale regola è un database è in grado di eseguire il cast. (Verranno presto alcune conversioni di tipi cleverer in una versione futura di Entity Framework principale). Quindi, nella OnConfiguring, impostare la regola di sostituzione:
optionsBuilder.ReplaceService<SqliteTypeMapper,MySqliteTypeMapper>();
Perché è sostituire non il servizio EntityFinder? In primo luogo, dal momento che in genere il modo funziona. Tuttavia, in secondo luogo, perché è una classe generica, che consente di creare una nuova versione di più complessa e si è scelto di impostare tale compito ingrato riservato per il momento. Durante la creazione di ReplaceService per rendere più semplice sostituire servizi interni, è necessario tenere presente che è potrebbero modificare elementi interni di Core di Entity Framework e, pertanto, la sostituzione può essere problematico lungo la strada. Perché si trovano gli spazi dei nomi che terminano con la parola per uso interno, è possibile identificare questi abbastanza facilmente. Da Microsoft: "È in genere evitare modifiche di rilievo in non. Spazi dei nomi interno in minor e rilasci di patch".
Vale la pena evidenziazione (perché la causa un po' di un agitare al momento) è una correzione a un problema di prestazioni delle query asincrone che utilizzato il metodo Include, che è stato individuato come 1.0 doveva essere rilasciata. È stato risolto in breve tempo (vedere bit.ly/2faItD1 se si è interessati nei dettagli del) con una percentuale di 70 segnalata aumentare le prestazioni e fa anche parte della versione 1.1.
Conclusioni
Entity Framework principale dispone di molte funzionalità sofisticate. È estremamente importante da tenere presente il contenuto, cosa non è, novità e mai accingo a far parte di Entity Framework principale. La documentazione principale di Entity Framework sulla sua relazione con Entity Framework 6 (bit.ly/2fxbVVj) è una risorsa utile, nonché. È il punto, si decide di quando è destra per le applicazioni Entity Framework Core.
Per la maggior parte del lavoro che io, Entity Framework Core 1.1 presenta le API e funzionalità che sono necessarie. Come un professionista DDD, la possibilità di incapsulare le raccolte è confermato per me, anche se sono ancora in attesa per i mapping di tipo complesso deve essere incluso in modo è inoltre possibile utilizzare gli oggetti di valore nel mio modelli. Questa funzionalità è destinata la prossima versione di Entity Framework principale. Sono stato entusiasti di recente individuare che Entity Framework Core ha completato la volontà di essi, per definire un DbContext (non-rilevamento) di sola lettura. Avevo dimenticare completamente che è stato aggiunto all'inizio e faceva parte della 1.0 versione di Entity Framework principale. Ulteriori informazioni che nel mio blog post in bit.ly/2f75l8m.
Julie Lerman è un Microsoft MVP, mentore e consulente .NET che risiede nel Vermont. È possibile trovare le sue presentazioni su accesso ai dati e altri argomenti di .NET in occasioni di conferenze in tutto il mondo. Anna blog all'indirizzo thedatafarm.com ed è autore di "Programming Entity Framework" nonché Code First e un'edizione di DbContext, tutto da o ' Reilly Media. Seguirla su Twitter: @julielerman e vedere proprio corsi Pluralsight juliel.me/PS-video.
Grazie al seguente esperto tecnico Microsoft per la revisione dell'articolo: Rowan Miller
Viene illustrato in questo articolo nel forum di MSDN Magazine