Considerazioni sulla migrazione (Entity Framework)

ADO.NET Entity Framework offre diversi vantaggi alle applicazioni esistenti. Uno dei principali vantaggi consiste nella possibilità di utilizzare 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 ulteriori informazioni sui vantaggi derivanti dall'utilizzo di Entity Framework , vedere Panoramica su Entity Framework e 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. Tra queste figurano 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 di mapping 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 a Entity Framework di qualsiasi applicazione che utilizza .NET Framework a partire dalla versione 3.5 SP1, a condizione che Entity Framework 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 a partire da .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 SP1 e .NET Framework a partire dalla versione 3.5 SP1.

2. 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 ulteriori informazioni, vedere Procedura: definire manualmente i file di modello e di mapping (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 i file di mapping e di modellazione 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 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 concettuale. In tale stringa sono incapsulate le informazioni relative ai file di modello e di mapping e alla connessione all'origine dati. Per ulteriori informazioni, vedere Procedura: definire la stringa di connessione (Entity Framework).

4. Configurare il progetto Visual Studio.

   È necessario aggiungere i riferimenti agli assembly di Entity Framework e i file di modello e di mapping 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

A partire da .NET Framework versione 4, Entity Framework supporta gli oggetti POCO ("plain old" CLR objects), denominati anche oggetti che non riconoscono la persistenza. Nella maggior parte dei casi, gli oggetti esistenti possono essere utilizzati con Entity Framework apportando piccole modifiche. Per ulteriori informazioni, vedere Utilizzo di entità POCO (Entity Framework). È possibile inoltre eseguire la migrazione di un'applicazione a Entity Framework e utilizzare le classi di dati generate dagli strumenti di Entity Framework. Per ulteriori informazioni, vedere Procedura: utilizzare la procedura guidata Entity Data Model (Entity Framework).

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 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.

• Utilizzo di set di dati.
  Entity Framework 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 Utilizzo di oggetti (Entity Framework).

  Se Entity Framework 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 concettuale Entity Framework 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 Compilazione di applicazioni a più livelli (Entity Framework).

• 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 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 e disconnessione di oggetti (Entity Framework).

Vedere anche

Concetti

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