Press "Enter" to skip to content

10 – Lavorare con i Dati – UsersDb le librerie Database aggiuntive

In questo articolo, creiamo le librerie dati per gli altri 2 database. Se non lo avete già notato, avevo già inserito nel progetto di test il Backup del Database SQL Server originale, e i due database simili Access e SQLite. In modo che li abbiate a disposizione. Copierò i 2 database sulle cartelle C:\TestAccessDb e C:\TestSqliteDb così come abbiamo fatto nella prima serie di articoli dedicati ai database per i nostri progetti di test.

10_usersdb_07_databases

La prima operazione che faremo nella soluzione, sarà generare la prima delle due nuove librerie data provider, quella relativa ad Access, ovvero la libreria OleDb in seguito genereremo la seconda libreria, per SQLite.

Perché due nuove librerie invece che generare le classi nella libreria dati già generata?

Prima risposta: Perché quella libreria si chiama SqlServerDp, perciò non può ospitare gli altri DB.

Seconda risposta, un po’ più seria: Stiamo simulando di creare una applicazione Multi Tier in grado di lavorare su più database, anche se nel nostro caso c’è una sola tabella, nel mondo reale, useremo dei database con tante tabelle, pertanto il codice per gestire ogni tabella su ciascuno dei database che vorremo supportare sarà piuttosto complesso, ed è opportuno quindi separare le librerie in modo tale che qualsiasi modifica, manutenzione, nuova implementazione può essere gestita nel modo più consono.

Andiamo quindi sulla Solution e inziamo aggiungendo il primo progetto class library dedicato ad Access, o meglio a qualsiasi database OleDb.

10_usersdb_01_add_oledbdp

Generiamo la nuova libreria OleDbDp all’interno della nostra solution e andiamo anche in questo caso a effettuare subito le modifiche di base che saranno:

  • Cancellare Class1.cs
  • Rinominare l’assembly Dnw.OleDbDp
  • Modificare il Default Namespace in Dnw.Data.OleDb
  • Modificare l’AssemblyInfo per inserire delle descrizioni opportune.
  • Aggiungere lo Strong name all’assembly.

Prima di proseguire, aggiungiamo anche in OleDbDp il riferimento alla libreria UsersEntities in modo che possiamo usare l’oggetto User.

10_usersdb_02_add_reference_oledbdp

Qui sopra la finestra per l’aggiunta del Reference alla libreria.

Creato e configurato il progetto possiamo procedere in 2 modi, il primo è il metodo da programmatori diligenti, ma è anche un metodo lungo e tedioso, ovvero: creiamo la classe UsersDp anche in questo progetto e scriviamo il codice che utilizza la libreria OleDb di .Net:

Ma essendo dei programmatori che amano ottimizzare il loro tempo e non sprecarne troppo quello che faremo è: copiare ed incollare la classe UsersDp.cs che si trova in SqlServerDp, e modificarla nel seguente modo:

  1. Modificare gli using sostituendo:
    • using System.Data.SqlServer con:
    • using System.Data.OleDb.
  2. Modificare il namespace sostituendo:
    • namespace Dnw.Data.SqlServer con
    • namespace Dnw.Data.OleDb.
  3. Sostituire le seguenti classi:
    • SqlConnection con OleDbConnection
    • SqlCommand con OleDbCommand
    • SqlParameter con OleDbParameter
    • SqlDataReader con OleDbDataReader

Una volta effettuate queste sostituzioni, nella nostra classe UsersDp, comunque rimarranno alcuni errori da correggere, e l’error list di Visual Studio sarà più o meno questa:

10_usersdb_03_errors_oledb

Come potete notare, gli errori sono 2:

  1. Manca il metodo extension XxTryParseToDbNull.
  2. Manca il metodo extension XxCheckDbNull.

Questo perché li abbiamo inseriti nella libreria SqlServerDp.

Prima di decidere come risolvere il problema, due righe di saggezza dinosauresca…

Questo tipo di situazione vi occorrerà decine se non centinaia di volte nei vostri progetti, anche per motivi molto meno evidenti di questo, quello che consiglio sempre è:

  • Valutate bene se una classe può essere riutilizzata più volte anche in progetti diversi da quello corrente.
    • se la risposta alla domanda è SI, createvi una libreria generica riutilizzabile in tutte le vostre future applicazioni (se cercate gli articoli sulle librerie base Dotnetwork pubblicati in passato da me vi trovate in dettaglio come, dove e perché).
    • Se la risposta è NO e una classe vi serve in diverse librerie in un vostro progetto, ma non servirà al di fuori di questo progetto create una libreria di uso comune del progetto che possa essere referenziata da tutti i progetti.
  • ATTENZIONE! che non vi passi per la mente di referenziare la libreria SqlServerDp nella libreria OleDbDp, perché questo è il modo migliore per farvi tanto, tanto, tanto male creando delle dipendenze circolari per il compilatore.
  • E’ sempre meglio creare un progetto in più che mandare in tilt le compilazioni a causa di questo tipo di dipendenze.

Come risolviamo il problema?

I nostri metodi Extension, sono stati definiti all’interno di una classe helper che abbiamo chiamato DbNullExtensions.cs, considerato che queste extension le potremo riutilizzare quante volte vogliamo e probabilmente le useremo anche in progetti diversi da questo (ma non allarghiamoci troppo per ora) creiamo una nuova libreria che possiamo chiamare ad esempio UsersData, dove andremo a spostare la classe con le extension. Anche questa, sarà una Class Library.

10_usersdb_04_usersdbData_library

Ecco la nostra libreria che genereremo spostandoci sulla Solution e usando il menu contestuale e l’opzione Add > New Project.

  • Sceglieremo Classic Desktop -> Class Library
  • Modificheremo il nome in UsersData

Una volta creato il progetto:

  • Cancelliamo Class1.cs
  • Andiamo nelle Property e Cambiamo il nome dell’assembly in Dnw.UsersData.
  • Cambiamo il namespace di default in Dnw.Data.
  • Apriamo l’Assembly Info e diamo delle descrizioni significative alla libreria.
  • Cambiamo l’icona standard con quella personalizzata usata anche per le altre librerie.
  • Firmiamo l’assembly usando la chiave Dotnetwork usata per gli altri assembly.
  • Copiamo DbNullExtensions.cs dal progetto SqlServerDp in questo progetto.
  • Modifichiamo il namespace della classe da
    • Dnw.Data.SqlServer a Dnw.Data
  • Cancelliamo DbNullExtensions.cs dal progetto SqlServerDp altrimenti sarebbe duplicato.

Ricompiliamo questa libreria (menu contestuale sul progetto e Build).

Poi andiamo ad aggiungere il Reference alla nuova libreria sia su SqlServerDp che su OleDbDp.

10_usersdb_05_usersdbData_reference

Una volta aggiunto il reference alla nuova libreria, gli errori (che saranno comparsi anche in SqlServerDp dopo la cancellazione di DbNullExtensions) spariscono ed entrambe le librerie sono funzionanti.

Creiamo anche la libreria SQLiteDp

Adesso che abbiamo estratto le extension, creare la libreria dati per SQLite sarà sicuramente un gioco da ragazzi, quindi listeremo le operazioni da farsi velocemente:

  1. Aggiungiamo alla Solution una nuova class library che chiamiamo SQLiteDp.
  2. Cancelliamo Class1.cs.
  3. In Property del progetto
    • Modifichiamo il nome assembly da SQLiteDp in Dnw.SQLiteDp
    • Modifichiamo il Default namespace in Dnw.Data.SQLite
    • Aggiorniamo le Assembly Information con dei dati significativi per la libreria.
    • Cambiamo l’icona standard con quella personalizzata dotnetwork.
    • Firmiamo l’assembly usando la chiave Dotnetwork usata per tutti gli altri assembly.
  4. Aggiungiamo un reference alla libreria SQLite che abbiamo installato nel primo articolo in cui abbiamo spiegato l’uso dei database:
    • Lavorare con i dati – Database e .net dove trovate come abbiamo installato SQLite se non lo aveste letto ancora.
    • Avendolo già installato andiamo a referenziare la libreria e copiamo nel progetto SQLite.Interop.dll (il perché lo trovate nell’articolo indicato al punto precedente).

10_usersdb_06_sqlitedp_sqlitereference

  1. Aggiungiamo i reference dal progetto a UsersEntities e UsersData.
  2. Copiamo la classe UsersDp dal progetto SqlServerDp al nuovo progetto.

Ora modifichiamo la classe in modo da utilizzare SQLite:

  1. Modifichiamo using System.Data.SqlServer in using System.Data.SQLite.
  2. Modifichiamo namespace Dnw.Data.SqlServer in namespace Dnw.Data.SQLite.
  3. Sostituiamo gli oggetti dati:
    • SqlConnection con SQLiteConnection.
    • SqlCommand con SQLiteCommand.
    • SqlParameter con SQLiteParameter.
    • SqlDataReader cib SQLiteDataReader.

A questo punto compiliamo e dovrebbe essere tutto a posto.

Riepilogo:

In questo articolo abbiamo discusso le seguenti cose:

  • Perché creare librerie separate per ogni database che supporteremo
  • Come creare la libreria OleDb data provider (per Access)
  • Perché creare una libreria di supporto con classi usate da più data provider
  • Come creare la libreria di supporto e spostarvi le Extension create per la gestione dei DbNull.
  • Come completare le librerie SqlServer e OleDb dopo la modifica.
  • Come generare la libreria data provider per SQLite.

Nella prossima puntata, testeremo il funzionamento delle tre librerie nuovamente, in modo da essere certi che qualsiasi database scelto per la nostra applicazione funzionerà correttamente.

Potete scaricare il progetto di esempio al link qui indicato:

Per qualsiasi domanda, curiosità, approfondimento, o per segnalare un errore non esitate ad utilizzare il link alla form di contatto in cima alla pagina.