Guest post: Introduzione a Visual Studio LightSwitch (2a parte)

Questo è il secondo post della serie “Guest post” che ospita autori esterni al team di MSDN Italia.

Questo post è stato scritto da Alessandro Del Sole, MVP Visual Basic e fondatore della prima community italiana su LightSwitch. Se volete proporre post per questa sezione, scriveteci.

Introduzione

Continuiamo la nostra esplorazione delle caratteristiche più importanti di Visual Studio LightSwitch, iniziata nel precedente post, introducendo due interessanti caratteristiche: specificare delle query per gli Screen direttamente in fase di progettazione e specificare delle regole di validazione personalizzate. Nel corso del post si farà riferimento alle figure incluse nella precedente discussione.

Query e ordinamento negli Screen in fase di progettazione

Molto spesso nelle nostre applicazioni business possiamo avere la necessità di filtrare dei dati in base a specifici criteri. In particolare possiamo avere la necessità di presentare all’utente il risultato del filtro, senza intaccare i rimanenti dati. Con Visual Studio LightSwitch questo è molto semplice, poiché è possibile assegnare delle query agli Screen desiderati, specificato anche i criteri direttamente in fase di progettazione e senza scrivere codice. Riprendendo l’applicazione di esempio mostrata nel post precedente, possiamo ipotizzare di voler mostrare all’utente solo l’elenco degli ordini la cui destinazione è l’Italia. E’ quindi sufficiente selezionare lo screen di ricerca (nell’esempio è chiamato SearchOrder) e nel designer fare click su Edit Query come si evince dalla seguente figura:

Questo attiverà l’editor delle query che ci permetterà di specificare il tipo di filtro (Where o Where Not) e quale proprietà vada filtrata:

Si noti come sia anche possibile risalire a proprietà dell’oggetto relazionato (in questo caso Customer). ShipCountry è la proprietà di nostro interesse e va selezionata. Quindi è possibile specificare il criterio vero e proprio, da un elenco decisamente completo:

Infine è possibile specificare il valore di confronto che può essere Literal (ossia una parola scritta da noi), Property (ossia una proprietà dell’oggetto corrente o di quello relazionato) o Parameter (che permette di specificare un parametro per la query).

Si noti come sia anche possibile specificare un criterio di ordinamento:

Se eseguiamo l’applicazione noteremo come la maschera di ricerca degli ordini mostri i soli risultati che hanno come valore della proprietà ShipCountry, proprio Italy:

Inoltre il risultato stesso è stato ordinato secondo le regole precedentemente specificate, come si evidenzia, fra l’altro, grazie alla freccetta di colore nero vicino all’intestazione di colonna OrderDate.

In questo modo è stato quindi possibile specificare query e ordinamento direttamente in fase di progettazione e senza scrivere codice, sebbene, ovviamente, sia comunque possibile personalizzare tali operazioni scrivendo codice apposito.

Validazione personalizzata dei dati

Nel post precedente abbiamo visto come LightSwitch offra un sistema integrato di validazione dei dati che, in molti casi, non richiede alcun intervento da parte dello sviluppatore, poiché esistono delle regole di validazione di default che, quando violate, vengono automaticamente comunicate all’utente mediante l’interfaccia grafica e costringono l’utente a risolvere il problema prima di salvare i dati. In particolare abbiamo visto l’esempio degli indirizzi email che, grazie al nuovo tipo di dato EmailAddress, offrono delle regole built-in. Ovviamente la validazione dei dati può andare ben oltre il singolo tipo di dato e spesso si ha la necessità di validare anche valori rispetto ad altre proprietà. Ciò premesso, esiste la possibilità di scrivere delle regole di validazione personalizzate, tramite codice Visual Basic o Visual C#. Sempre continuando il precedente esempio, con riferimento alla tabella Order ci sono due date: quella dell’ordine e quella di consegna. Nessuna regola di validazione built-in può prevedere, ad esempio, di controllare che la data di consegna non sia precedente a quella dell’ordine perché siamo in uno scenario custom. Di conseguenza diventa importante scrivere una regola personalizzata. Senza entrare a fondo nei dettagli dell’architettura del sistema di validazione, per i quali vi rimando a questo post sul blog del Team di LightSwitch, molto semplicemente possiamo dapprima aprire la tabella Order, quindi selezionare la proprietà RequiredDate, infine fare click su Custom Validation nella Finestra delle proprietà:

Questo attiverà l’editor di codice, all’interno del quale potremo scrivere la nostra regola di validazione in un metodo che gestisce l’evento Validate della proprietà desiderata:

A tal proposito bisogna osservare che:

1. Il metodo non restituisce alcun valore, piuttosto è una variabile passata per riferimento che conterrà il risultato della validazione

2. Per aggiungere un errore di validazione si utilizza il metodo AddPropertyError che aggiunge l’errore specificato alla collezione di errori.

3. L’errore così aggiunto sarà notificato all’interfaccia grafica, la quale si farà carico di comunicarlo all’utente.

Campi calcolati

LightSwitch permette di aggiungere alle tabelle anche i cosiddetti campi calcolati (computed fields) ossia campi il cui valore viene determinato solo a runtime e che quindi non viene memorizzato nel data store. Questo può essere molto utile nel caso di calcoli matematici come somme, totali di importi in valuta, conteggio totale degli elementi in una tabella. Ipotizzando di voler visualizzare il numero totale degli ordini di ciascun cliente, proseguendo il nostro esempio eseguiremo i seguenti passaggi:

1. Apertura della tabella Customer

2. Click sul pulsante Add Computed Property.

3. Quando il campo viene aggiunto alla tabella, lo rinominiamo in TotalOrders di tipo Int32.

4. Nella Finestra delle Proprietà click su Edit Method. Questo farà si che venga aperto l’editor di codice, all’interno del quale potremo scrivere codice che esegua il calcolo matematico richiesto, come nel seguente esempio:

Si noti come, anche in questo caso, il gestore di evento Compute non restituisce un valore ma assegna il risultato a una variabile passata per riferimento. Nel momento in cui l’applicazione viene eseguita, viene anche mostrato il risultato del calcolo:

In questo modo è stato ottenuto un valore calcolato a runtime e che non è memorizzato nel database, con i vantaggi in termini di memorizzazione e performance che questo può comportare soprattutto in scenari reali con dati complessi.