Considerazioni sulla migrazione (Entity Framework)

ADO.NET Entity Framework offre diversi vantaggi alle applicazioni esistenti. Uno dei principali vantaggi consiste nella possibilità di utilizzare Entity Data Model (EDM) 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 ulteriori informazioni sui vantaggi derivanti dall'utilizzo di Entity Framework, vedere Introduzione a Entity Framework.

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. Tra queste figurano l'aggiornamento dell'applicazione per l'uso di .NET Framework 3.5 Service Pack 1 (SP1), la definizione del modello EDM e la configurazione di Entity Framework. Quando si esegue la migrazione di un'applicazione a Entity Framework occorre 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 utilizzare quando si aggiorna un'applicazione esistente.

Considerazioni generali sulla migrazione

Le considerazioni seguenti riguardano l'esecuzione della migrazione di un'applicazione ad Entity Framework:

• È possibile eseguire la migrazione delle applicazioni che utilizzano .NET Framework 3.5 a Entity Framework, a condizione che quest'ultimo sia supportato dal provider di dati dell'origine dati utilizzata dall'applicazione.

• 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 utilizzano Entity Framework quando si cambia l'origine dati.

• La connessione al provider di dati utilizzata da Entity Framework può essere condivisa con altre parti dell'applicazione in quanto Entity Framework utilizza provider di dati ADO.NET per accedere all'origine dati. Il provider SqlClient viene ad esempio utilizzato 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 dal tipo di applicazione e dalla strategia di accesso ai dati esistente. È invece necessario effettuare sempre le attività seguenti quando si esegue la migrazione di un'applicazione esistente a Entity Framework.

Nota
Tutte le attività indicate vengono eseguite automaticamente quando si utilizzano gli strumenti di Entity Data Model con Visual Studio 2008. Per ulteriori informazioni, vedere Procedura: utilizzare la procedura guidata Entity Data Model (Entity Framework).

1. Aggiornamento dell'applicazione.

   È necessario aggiornare i progetti creati con una versione precedente di Visual Studio e .NET Framework per l'utilizzo di Visual Studio 2008 SP1 e .NET Framework 3.5 SP1. Per ulteriori informazioni, vedere Conversione guidata di Visual Studio.

2. Definizione di Entity Data Model (EDM).

   Nel modello concettuale EDM vengono definiti le entità, ovvero le strutture dell'origine dati, quali tabelle, stored procedure e viste, e il mapping tra le entità e tali strutture. Per ulteriori informazioni, vedere Procedura: definire manualmente un modello EDM (Entity Framework).

   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 ulteriori informazioni, vedere Procedura: personalizzare un modello EDM per l'utilizzo con oggetti personalizzati (Entity Framework).

   Nota
   Entity Data Model Designer consente di rinominare le entità presenti nel modello concettuale in modo che corrispondano agli oggetti esistenti. Per ulteriori informazioni, vedere Cenni preliminari su ADO.NET Entity Data Model Designer.

3. Definizione della stringa di connessione.

   In Entity Framework viene utilizzata una stringa di connessione con formattazione speciale per l'esecuzione di query sul modello EDM. In tale stringa sono incapsulate le informazioni relative ai file di mapping EDM e alla connessione all'origine dati. Per ulteriori informazioni, vedere Procedura: definire la stringa di connessione (Entity Framework).

4. Configurazione del progetto Visual Studio.

   È necessario aggiungere i riferimenti agli assembly di Entity Framework e il modello EDM al progetto 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 ulteriori informazioni, vedere Procedura: configurare manualmente un progetto di Entity Framework.

Considerazioni per le applicazioni con oggetti esistenti

Quando si esegue la migrazione di un'applicazione a Entity Framework, la modalità con cui vengono migrate le classi di dati esistenti dipende dalla logica di business, dai metodi personalizzati e dalla convalida delle proprietà implementati nelle classi. Per utilizzare le classi di dati esistenti è necessario selezionare uno degli approcci seguenti.

• Se le classi di dati esistenti ottengono e impostano solo le proprietà degli oggetti, sostituirle con i tipi di entità generati dagli strumenti Entity Data Model. Per ulteriori informazioni, vedere Procedura: utilizzare la procedura guidata Entity Data Model (Entity Framework).

• Se le classi di dati implementano il codice di convalida personalizzato o altra logica di business, eseguire la migrazione della logica nelle classi parziali generate dagli strumenti Entity Data Model. Gli strumenti Entity Data Model generano tipi di entità come classi parziali. In questo modo è possibile riutilizzare i metodi e le proprietà convertendo le classi esistenti in classi parziali. Quando si esegue questa operazione, è necessario rimuovere dall'applicazione esistente qualsiasi proprietà duplicata nella classe generata. Per informazioni sulla creazione di classi parziali, vedere Personalizzazione di oggetti (Entity Framework).

  Per ogni proprietà di una classe di dati, gli strumenti Entity Framework generano i metodi parziali denominati OnNomeProprietàChanging e OnNomeProprietàChanged, in cui è possibile trasferire il codice di convalida delle proprietà esistente. Per ulteriori informazioni, vedere Procedura: eseguire la logica di business quando vengono modificate le proprietà (Entity Framework).

• Se si desidera mantenere le classi di dati esistenti perché contengono una quantità significativa di codice personalizzato o per altri motivi, è necessario effettuare una delle operazioni seguenti:

  • Modificare le classi di dati in modo che ereditino dalla classe EntityObject o ComplexObject. Tutti i tipi EDM generati ereditano da EntityObject o ComplexObject e Entity Framework consente di utilizzare classi di dati personalizzate ereditando da queste classi di base. Si tratta della modalità consigliata di utilizzo delle classi di dati personalizzate con un modello EDM. Per ulteriori informazioni, vedere Personalizzazione di oggetti (Entity Framework).

  • Modificare le classi di dati per implementare un set di interfacce. Eseguire tale operazione se le classi di dati non possono ereditare da EntityObject o ComplexObject. Per ulteriori informazioni sull'implementazione di tali interfacce, vedere Personalizzazione di oggetti (Entity Framework).

Nota
Quando si utilizzano classi di dati esistenti o classi parziali con un modello EDM, i nomi delle classi devono corrispondere a quelli delle entità definite nel modello concettuale. Utilizzare Entity Designer per rinominare le entità. Per ulteriori informazioni, vedere Procedura: creare e modificare i tipi di entità.

Considerazioni per le applicazioni che utilizzano provider ADO.NET

I provider ADO.NET, ad esempio SqlClient, consentono di eseguire query su un'origine dati in modo che vengano restituiti dati tabulari. I dati possono anche essere caricati 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 utilizza un provider ADO.NET esistente:

• Visualizzazione di dati tabulari mediante un lettore dati.
  È possibile eseguire una query Entity SQL utilizzando il provider EntityClient ed effettuando l'enumerazione dell'oggetto EntityDataReader restituito. Eseguire questa operazione solo se l'applicazione visualizza dati tabulari mediante un lettore dati e non richiede le funzionalità offerte da Object Services 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.

• Utilizzo di set di dati.
  In Entity Framework, Object Services offre gran parte delle stesse funzionalità fornite dai set di dati, inclusi la persistenza in memoria, il rilevamento delle modifiche, l'associazione dati e la serializzazione degli oggetti come dati XML. Per ulteriori informazioni, vedere Cenni preliminari su Object Services (Entity Framework).

  Se Object Services non fornisce la funzionalità del set di dati necessaria per l'applicazione, è possibile sfruttare comunque i vantaggi delle query LINQ utilizzando LINQ to DataSet. Per ulteriori informazioni, vedere LINQ to DataSet.

Considerazioni per le applicazioni che associano dati ai controlli

.NET Framework consente di incapsulare dati in un'origine dati, ad esempio un set di dati o un controllo origine dati ASP.NET, quindi di associare elementi dell'interfaccia utente ai controlli 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 EDM, Object Services restituisce i dati sotto forma di oggetti che sono istanze di tipi di entità. Tali oggetti possono essere associati direttamente a controlli e l'associazione definita supporta gli aggiornamenti. In altre parole, le modifiche apportate ai dati di un controllo, ad esempio una riga in un oggetto DataGridView, vengono automaticamente salvate 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.

  Per ulteriori informazioni, vedere Associazione di oggetti ai controlli (Entity Framework).

• Controlli origine dati ASP.NET.
  In Entity Framework è incluso un controllo origine dati progettato per semplificare l'associazione dati nelle applicazioni Web ASP.NET. Per ulteriori informazioni, vedere Controllo origine dati di Entity Framework.

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 utilizzando un formato di messaggistica di richiesta/risposta XML. Entity Framework supporta la serializzazione degli oggetti entità mediante la serializzazione dei contratti di dati WCF, binaria o XML. I tipi di serializzazione binaria e WCF implicano la serializzazione completa degli oggetti grafici. Per ulteriori informazioni, vedere Servizi Web e Entity Data Model (scenari applicativi).

• Applicazioni che utilizzano dati XML.
  La serializzazione degli oggetti consente di creare servizi di dati di Entity Framework. Tali servizi forniscono dati alle applicazioni che utilizzano dati XML, quali le applicazioni Internet basate su Ajax. In questi casi, utilizzare ADO.NET Data Services. I servizi di dati 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 ulteriori informazioni, vedere Framework di ADO.NET Data Services.

  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 ulteriori informazioni, vedere Serializzazione di oggetti (Entity Framework).

  Se l'applicazione richiede la funzionalità di query sui dati XML, è comunque possibile sfruttare i vantaggi delle query LINQ utilizzando LINQ to XML. Per ulteriori informazioni, vedere LINQ to XML.

• Applicazioni che gestiscono lo stato.
  Le applicazioni Web ASP.NET devono gestire frequentemente lo stato di una pagina Web o di una sessione utente. Gli oggetti presenti in un'istanza di ObjectContext possono essere archiviati nello stato di visualizzazione del client o nello stato della sessione sul server ed essere successivamente recuperati e riassociati a un nuovo contesto dell'oggetto. Per ulteriori informazioni, vedere Connessione di oggetti (Entity Framework).

Vedere anche

Concetti

Considerazioni relative alla distribuzione (Entity Framework)
Terminologia relativa a Entity Framework

Altre risorse

Attività di Entity Framework