Entity Framework, da dove si parte?

di il
2 risposte

Entity Framework, da dove si parte?

Ciao a tutti, spero di trovare un po' di aiuto e conforto.
Arrivo qui dopo un po' di infruttuose ricerche, probabilmente non riesco a inquadrare bene l'argomento.

Devo fare un po' di premesse.

Le mie soluzioni in C# sono sviluppate di solito in VS2019 o VS2022 e sono costituite spesso da due progetti: una App Windows Forms (.NET Framework) e una Libreria di classi (.NET Framework).

Di base realizzo applicativi tipo gestionali connessi a un database MS SQL Server. Per quello che ho imparato finora, nella libreria vado a creare:
  • la connection string direttamente nelle impostazioni del progetto
  • gli oggetti DataSet (tasto dx sul progetto > Aggiungi... > Nuovo elemento... > Elementi di Visual C# > Dati > DataSet)

Poi nei DS vado a creare i vari TableAdapter.

Il progetto app avrà tra i suoi riferimenti il progetto libreria, e nelle varie form inserisco le istanze dei DS che mi servono. A queste faccio riferire gli oggetti BindingSource, ai quali, a loro volta, lego i binding sui controlli tipo label, textbox, datagridview. Scrivo il codice per i vari eventi per la lettura/scrittura, compilo, distribuisco... funziona tutto.

Mi sono reso conto però che anche in fase di sviluppo sto lavorando sempre sul database di produzione. Certo, con il MS SQL Server Management Studio posso duplicare il DB di produzione per avere un DB per testare... ma per usarlo devo cambiare la connection string usata dai DataSet; se quella volta, per la fretta, mi dimentico di farla puntare di nuovo al DB di produzione, distribuisco una app che non lavora con il database giusto! Se non sbaglio non è agevole cambiare la connection string in runtime, per esempio per farla "modificare" all'utente in una form di selezione del database a cui puntare... almeno io non ho capito come fare.

Facendo un po' di ricerche, mi sono imbattuto in un concetto "nuovo": Entity Framework. Da quello che ho capito si tratta essere una sorta di layer a metà tra strada tra la parte legata alla business logic della mia applicazione e la parte che si interfaccia verso il database. È così?
Ho visto che si può usare EF in modi diversi, con il paradigma DataBase-First oppure Code-First (e mi sembra anche Model-First, ma non ho ben capito). Mi piacerebbe poter avere un sistema che permette di lavorare in maniera visuale come con i DataSet e il binding sui controlli, senza che io sia connesso a un database durante lo sviluppo; e che mi permetta in runtime di collegarmi a un database esistente (fermo restando che abbia naturalmente la stessa struttura dei modelli previsti in fase di sviluppo), o addirittura a generare un nuovo database sulla base di quei modelli.

È la strada giusta? Qualcuno sa indicarmi eventualmente delle fonti per approfondire? (vi prego, non video-tutorial... )

Grazie a tutti per l'attenzione

2 Risposte

  • Re: Entity Framework, da dove si parte?

    In due parole, Entity Framework è un tool ORM, ossia uno strumento per accedere ai dati sfruttando un layer di classi che offra la possibilità di manipolarli senza necessariamente fare uso del linguaggio SQL, che è pressoché un "estraneo" se si considerano principi come la OOP e affini.

    Ad ogni modo, parlandone così ad alto livello, ci sarebbe troppo da scrivere: prova a partire da questo sito e ad approfondire le funzionalità di questo framework basato su LINQ.

    Magari sul forum si possono evidenziare dubbi specifici qualora non dovessero essere chiari dalla spiegazione generale.

    Ciao!
  • Re: Entity Framework, da dove si parte?

    Grazie Marco per la condivisione del materiale!

    Approfondirò sicuramente... peraltro LINQ mi è già noto e lo uso spesso per fare selezioni o proiezioni in runtime su piccoli set di dati in svariate procedure.

    Nel frattempo sono riuscito a trovare una soluzione per me accettabile al mio problema, che era quello di utilizzare un set di dati che fosse locale e distribuibile.

    Credo di aver capito dove stessi sbagliando: non stavo gestendo in maniera corretta i file MDF, mi limitavo ad aggiungerli al progetto per poi usarli direttamente.
    La soluzione che ho trovata è stata quella di importare tra le risorse del "progetto libreria" i file MDF necessari (uno per ogni schema DB), e quindi a design time lavorare come al solito connettendomi a questi schemi per realizzare i file XSD dei modelli di dataset in modo visuale. In questo modo posso realizzare i binding ai controlli sensibili ai dati nelle form, anche da progetti diversi. In runtime faccio copiare i file MDF dalle Properties.Resources nel filesystem del cliente. L'accesso e la gestione dei dati magari risulta un po' meno immediato, ma mi sono scritto le classi necessarie per occuparmi della parte SQL e delle operazioni di inserimento/modifica/cancellazione.

    Sono abbastanza soddisfatto.
Devi accedere o registrarti per scrivere nel forum
2 risposte