Considerazioni sulla migrazione (Entity Framework)
Entity Framework ADO.NET offre diversi vantaggi alle applicazioni esistenti. Uno dei principali vantaggi consiste nella possibilità di usare un modello concettuale per separare le strutture di dati impiegate dall'applicazione dallo schema presente nell'origine dati in modo da apportare facilmente modifiche future al modello di archiviazione o all'origine dati stessa senza effettuare modifiche di compensazione nell'applicazione. Per altre informazioni sui vantaggi dell'uso di Entity Framework, vedere Panoramica di Entity Framework ed Entity Data Model.
Per sfruttare i vantaggi di Entity Framework, è possibile eseguire la migrazione di un'applicazione esistente a Entity Framework. Alcune attività sono comuni a tutte le applicazioni migrate. Queste attività comuni includono l'aggiornamento dell'applicazione per l'uso di .NET Framework a partire dalla versione 3.5 Service Pack 1 (SP1), la definizione di modelli e il mapping e la configurazione di Entity Framework. Quando si esegue la migrazione di un'applicazione a Entity Framework, è necessario tenere presenti considerazioni aggiuntive. che dipendono dal tipo di applicazione migrato e dalla funzionalità specifica dell'applicazione. In questo argomento vengono fornite informazioni grazie alle quali è possibile scegliere l'approccio ideale da usare quando si aggiorna un'applicazione esistente.
Considerazioni generali sulla migrazione
Quando si esegue la migrazione di un'applicazione a Entity Framework, si applicano le considerazioni seguenti:
Qualsiasi applicazione che usa .NET Framework a partire dalla versione 3.5 SP1 può essere migrata a Entity Framework, purché il provider di dati per l'origine dati usata dall'applicazione supporti Entity Framework.
Entity Framework potrebbe non supportare tutte le funzionalità di un provider dell'origine dati, anche se supportato da tale provider.
Nel caso di applicazioni complesse o di grandi dimensioni non è necessario eseguire la migrazione dell'intera applicazione a Entity Framework in una sola volta. È comunque necessario sostituire le parti dell'applicazione che non usano Entity Framework quando si cambia l'origine dati.
La connessione al provider di dati usata da Entity Framework può essere condivisa con altre parti dell'applicazione perché Entity Framework usa i provider di dati ADO.NET per accedere all'origine dati. Il provider SqlClient viene ad esempio usato da Entity Framework per accedere a un database di SQL Server. Per ulteriori informazioni, vedere Provider EntityClient per Entity Framework.
Attività comuni di migrazione
Il percorso per eseguire la migrazione di un'applicazione esistente a Entity Framework dipende sia dal tipo di applicazione che dalla strategia di accesso ai dati esistente. Tuttavia, è necessario eseguire sempre le attività seguenti quando si esegue la migrazione di un'applicazione esistente a Entity Framework.
Nota
Tutte queste attività vengono eseguite automaticamente quando si usano gli strumenti Entity Data Model a partire da Visual Studio 2008. Per altre informazioni, vedere Procedura: Usare la procedura guidata di Entity Data Model.
Aggiornamento dell'applicazione.
Un progetto creato usando una versione precedente di Visual Studio e .NET Framework deve essere aggiornato per usare Visual Studio 2008 SP1 e .NET Framework a partire dalla versione 3.5 SP1.
Definire i modelli e il mapping.
I file di modello e di mapping definiscono entità nel modello concettuale, ovvero le strutture dell'origine dati, quali le tabelle, le stored procedure e le visualizzazioni, e il mapping tra le entità e tali strutture. Per altre informazioni, vedere Procedura: Definire manualmente i file di modello e mapping.
I tipi definiti nel modello di archiviazione devono corrispondere al nome degli oggetti presenti nell'origine dati. Se nell'applicazione esistente i dati sono esposti come oggetti, è necessario assicurarsi che le entità e le proprietà definite nel modello concettuale corrispondano ai nomi delle proprietà e delle classi di dati esistenti. Per altre informazioni, vedere Procedura: Personalizzare i file di modellazione e mapping in modo che funzionino con oggetti personalizzati.
Nota
Entity Data Model Designer consente di rinominare le entità presenti nel modello concettuale in modo che corrispondano agli oggetti esistenti. Per altre informazioni, vedere Finestra di progettazione Entity Data Model.
Definizione della stringa di connessione.
In Entity Framework viene usata una stringa di connessione con formattazione speciale per l'esecuzione di query sul modello concettuale. In tale stringa sono incapsulate le informazioni relative ai file di modello e di mapping e alla connessione all'origine dati. Per altre informazioni, vedere Procedura: Definire la stringa di connessione.
Configurare il progetto di Visual Studio.
I riferimenti agli assembly di Entity Framework e ai file di modello e mapping devono essere aggiunti al progetto di Visual Studio. L'aggiunta di tali file di mapping al progetto consente di garantirne la distribuzione con l'applicazione nel percorso indicato nella stringa di connessione. Per altre informazioni, vedere Procedura: Configurare manualmente un progetto Entity Framework.
Considerazioni per le applicazioni con oggetti esistenti
A partire da .NET Framework 4, Entity Framework supporta oggetti CLR "plain old" (POCO), detti anche oggetti che non riconoscono la persistenza. Nella maggior parte dei casi, gli oggetti esistenti possono funzionare con Entity Framework apportando modifiche minime. Per altre informazioni, vedere Uso di entità POCO. È inoltre possibile eseguire la migrazione di un'applicazione a Entity Framework e usare le classi di dati generate dagli strumenti di Entity Framework. Per altre informazioni, vedere Procedura: Usare la procedura guidata di Entity Data Model.
Considerazioni per le applicazioni che usano provider ADO.NET
I provider ADO.NET, ad esempio SqlClient, consentono di eseguire query su un'origine dati per restituire dati tabulari. I dati possono essere caricati anche in un set di dati di ADO.NET. Nell'elenco seguente vengono riportate e illustrate le considerazioni che riguardano l'aggiornamento di un'applicazione che usa un provider ADO.NET esistente:
Visualizzazione di dati tabulari mediante un lettore dati.
È possibile prendere in considerazione l'esecuzione di una query Entity SQL usando il provider EntityClient e l’enumerazione tramite l'oggetto restituito EntityDataReader. Eseguire questa operazione solo se l'applicazione visualizza dati tabulari mediante un lettore dati e non richiede le funzionalità offerte da Entity Framework per la materializzazione dei dati in oggetti, il rilevamento delle modifiche e l'applicazione di aggiornamenti. È possibile continuare a utilizzare il codice di accesso ai dati esistente che applica gli aggiornamenti all'origine dati servendosi comunque della connessione esistente cui si accede dalla proprietà StoreConnection di EntityConnection. Per ulteriori informazioni, vedere Provider EntityClient per Entity Framework.
Uso di set di dati.
Entity Framework offre molte delle stesse funzionalità fornite da DataSet, tra cui persistenza in memoria, rilevamento delle modifiche, data binding e serializzazione di oggetti come dati XML. Per altre informazioni, vedere Uso di oggetti.
Se Entity Framework non fornisce la funzionalità di DataSet necessaria per l'applicazione, è comunque possibile sfruttare i vantaggi delle query LINQ usando LINQ to DataSet. Per altre informazioni, vedere LINQ to DataSet.
Considerazioni per le applicazioni che associano dati ai controlli
.NET Framework consente di incapsulare i dati in un'origine dati, ad esempio un oggetto DataSet o un controllo origine dati ASP.NET, quindi associare gli elementi dell'interfaccia utente a tali controlli dei dati. Nell'elenco seguente vengono riportate e illustrate le considerazioni relative all'associazione dei controlli ai dati di Entity Framework.
Associazione di dati a controlli.
Quando si esegue una query sul modello concettuale, Entity Framework restituisce i dati come oggetti che sono istanze di tipi di entità. Tali oggetti possono essere associati direttamente a controlli e l'associazione definita supporta gli aggiornamenti. Ciò significa che le modifiche ai dati in un controllo, ad esempio una riga in un oggetto DataGridView, vengono salvate automaticamente nel database quando viene chiamato il metodo SaveChanges.
Se l'applicazione enumera i risultati di una query per visualizzare i dati in un controllo DataGridView o in un altro tipo di controllo che supporti l'associazione dati, è possibile modificarla in modo da associare il controllo al risultato di un oggetto ObjectQuery<T>.
Per altre informazioni, vedere Associazione di oggetti ai controlli.
Controlli origine dati ASP.NET.
Entity Framework include un controllo origine dati progettato per semplificare il data binding nelle applicazioni Web ASP.NET. Per altre informazioni, vedere Panoramica controllo server Web EntityDataSource.
Altre considerazioni
Di seguito vengono riportate le considerazioni di cui è possibile tenere conto quando si esegue la migrazione di tipi specifici di applicazione a Entity Framework.
Applicazioni che espongono servizi di dati.
I servizi e le applicazioni Web basati su Windows Communication Foundation (WCF) espongono i dati provenienti da un'origine dati sottostante usando un formato di messaggistica di richiesta/risposta XML. Entity Framework supporta la serializzazione di oggetti entità tramite serializzazione di contratti di dati binari, XML o WCF. I tipi di serializzazione binaria e WCF implicano la serializzazione completa degli oggetti grafici. Per altre informazioni, vedere Compilazione di applicazioni a più livelli.
Applicazioni che usano dati XML.
La serializzazione degli oggetti consente di creare servizi dati di Entity Framework. Tali servizi forniscono dati alle applicazioni che usano dati XML, quali le applicazioni Internet basate su Ajax. In questi casi, prendere in considerazione l'uso di WCF Data Services. Tali servizi sono basati sul modello EDM e forniscono accesso dinamico ai dati delle entità tramite azioni HTTP REST (Representational State Transfer) standard, come GET, PUT e POST. Per altre informazioni, vedere WCF Data Services 4.5.
Entity Framework non supporta un tipo di dati XML nativo. Ciò significa che, quando viene eseguito il mapping di un'entità a una tabella con una colonna XML, la proprietà dell'entità equivalente della colonna XML è una stringa. Gli oggetti possono essere disconnessi e serializzati come XML. Per altre informazioni, vedere Serializzazione di oggetti.
Se l'applicazione richiede la funzionalità di query sui dati XML, è comunque possibile sfruttare i vantaggi delle query LINQ usando LINQ to XML. Per altre informazioni, vedere LINQ to XML (C#) o LINQ to XML (Visual Basic).
Applicazioni che gestiscono lo stato.
Le applicazioni Web ASP.NET devono mantenere spesso lo stato di una pagina Web o di una sessione utente. Gli oggetti in un'istanza ObjectContext possono essere archiviati nello stato di visualizzazione client o nello stato della sessione nel server e recuperati e ricollegati in un nuovo contesto di oggetto. Per altre informazioni, vedere Collegamento e scollegamento di oggetti.