LightSwitch & SQLite

Roberto Sarati — Sat, 04 Feb 2012 15:03:16 GMT

Premetto che non avrei mai scritto un post sull'argomento, però dato che mi piace fare delle considerazioni, ne sfrutto l'occasione.

Partiamo subito dalle considerazioni. LightSwitch è un prodotto Microsoft che permette di realizzare applicazioni 3-Tier in modo molto semplice e veloce.
Dall'uscita del prodotto, subito sono sorte domande la cui risposta (imho) è negativa ovvero:

Lightswitch è/tenta di sostituire Access? No. Access è Access, ha un altro target. Può sembrare simile, ma solo in lontananza.
E' possibile creare applicazioni 1-Tier? No. O meglio, LightSwitch non è pensato per questo.
E' possibile utilizzare strumenti/tecniche che l'ide non permette velocemente di utilizzare? Ni. Si può fare ma a vostro rischio e pericolo. Questo significa che si può fare con difficoltà, con difficoltà si manterrà nelle prossime versioni, con difficoltà si potrà deployare ecc ecc

Detto questo veniamo al punto. Imho, LS + SQLite = No. No perchè SQLite non è pensato per avere multiutenza (i lock vengono messi sul file intero==è come avere un lock su tutto il db), si può usare sqlserver express senza problemi, è 'complicato' da deployare.

Avendo premesso tutto questo (la parte secondo me importante), ecco come usare SQLite:

Utilizzare il provider ADO.NET scaricabile all'indirizzo http://system.data.sqlite.org.
Attualmente non è incluso l'addin per visual studio. Se servisse, installare il pacchetto (non più mantenuto) da http://sqlite.phxsoftware.com
Sviluppare aggiungendo un nuovo datasource e selezionando il provider SQLite.
Deployare l'applicazione normalmente.
Una volta effettuato il deploy, LS funziona correttamente ma è necessario configurare SQLite:

- aggiungere nella cartella di bin su IIS gli assembly dei provider: System.Data.Sqlite.dll e System.Data.Sqlite.Linq.dll. (attenzione alla versione x86 o x64)
- modificare il web.config per aggiungere il provider:
<system.data>
   <DbProviderFactories>
   <remove invariant="System.Data.SQLite"/>
     <add name="SQLite Data Provider" invariant="System.Data.SQLite" description=".Net Framework Data Provider for SQLite" type="System.Data.SQLite.SQLiteFactory, System.Data.SQLite" />
   </DbProviderFactories>
</system.data>
- copiare il database di SQLite in una cartella nuova (che chiamerò dbfolder).
- occorre dare i permessi di modifica/scrittura alla cartella dbfolder all'application pool (quindi IIS AppPool/DefaultAppPool o altro)
- modificare la connection string nel web.config con il percorso del database SQLit

Come si può notare, non è tanto un problema di LightSwitch, quanto di SQLite, dei provider ADO ecc.
E' vero che LS non è perfetto e migliorabile (cosa non lo è) però a volte la strada più semplice è la migliore.

[LightSwitch] Utilizzare l'ObjectContext ApplicationData da WCF Ria Service

Roberto Sarati — Wed, 30 Nov 2011 00:20:38 GMT

LightSwitch permette di creare/gestire un database al suo interno senza utilizzare strumenti esterni. Questo DB è chiamato ApplicationData e verrà generato in produzione, in fase di deploy, utilizzando una connection string impostata tramite widzard.

Cosa avviene in pratica:

- La connessione viene memorizzata, sempre con lo stesso nome "_IntrinsicData", all'interno del web.config deployato.
- l'ObjectContext di EF viene autogenerato nel file ServerGenerated\GeneratedArtifacts\ApplicationData.cs

Per utilizzare l'ObjectContext in un WCF Ria Service quindi basta:
- Aggiungere il file al progetto WCF Service (As Link dato che verrà rigenerato)
- Recuperare l'ObjectContext nel seguente modo:

EntityConnectionStringBuilder builder = new EntityConnectionStringBuilder();
builder.Metadata =
  "res://*/ApplicationData.csdl|res://*/ApplicationData.ssdl|res://*/ApplicationData.msl";
builder.Provider = "System.Data.SqlClient";
builder.ProviderConnectionString =
  WebConfigurationManager.ConnectionStrings["_IntrinsicData"].ConnectionString;
var context = new ApplicationDataObjectContext(builder.ConnectionString);

In questo modo è possibile:
- eseguire query complesse sul nostro db applicativo (quelle supportate dal provider di EF)
- sopperire alle "mancanze espressive" delle query linq generate in LightSwitch e poter utilizzare entità custom definite nella nostra libreria (per esempio a fine reportistici)