Demo 8 – Accesso ai Dati (parte 2) – Uso avanzato di XML

Abbiamo già detto che i database non sono l’unico modo per salvare lo stato della nostra applicazione. Esistono i file, ma non credo ci sia più nessuno disposto a programmare così a basso livello, se non per particolari esigenze di performance. Perciò, una alternativa più che buona è XML.

Per approcciare a XML esistono molte scuole di pensiero e ci sono ad oggi pro e contro abbastanza oggettivi. XML da un lato è interoperabile, è testuale ed è eye-friendly; dall’altro mappare un documento XML in DOM è una operazione abbastanza onerosa, soprattutto se il file è di grandi dimensioni. Un’altra questione da considerare è la crescita del file XML: se siamo discretamente certi che il file crescerà poco o sotto certi limiti/vincoli, allora possiamo procedere; se potenzialmente il file potesse raddoppiare le proprie dimensioni spesso, dobbiamo riflettere meglio se conviene usarlo o no.

NB: nell’XML per ogni elemento c’è un tag di lunghezza arbitraria che lo apre e lo chiude: questo genera un overhead incredibile in termini di spazio su disco impiegato.

Soluzione A: Implementare un parser custom per l’XML

Sebbene i parser siano sempre stati le soluzioni più performanti in ambito di XML, il parser ha un grosso problema e un’altro insormontabile. Quello grosso è che, una volta implementato ad-hoc per quel particolare file XML, un cambiamento allo schema e quindi alla struttura del file provoca il dover cambiare/riscrivere parti della logica del parser stesso.

Il problema insormontabile però resta il fatto che un parser non può scrivere sul file XML e, che se la scrittura è un MUST-HAVE nella nostra applicazione, con il parser ci facciamo ben poco.

Scartiamo la soluzione parser.

Soluzione B: Creare un mapping tipizzato dell’XML

Questa soluzione, decisamente potente ed estremamente elegante non solo ci consente di aprire, leggere e modficare il file XML con ragionevole semplicità; ci offre anche una elasticità ai cambiamenti di schema e delle performance considerevoli su file di discrete dimensioni. A differenza del parser però, se qui il file cresce troppo, il programma si blocca o crasha (conseguentemente all’esaurirsi della memoria disponibile).

Ora vediamo come impostare una struttura di questo tipo, passo passo:

1. Procuriamoci l’XML che vogliamo leggere. Notare che questa soluzione è decisamente comoda se dobbiamo valutare/elaborare molti file XML aventi lo stesso schema.
2. Procuriamoci l’XSD. Come si fa? O con qualche tool che avete installato localmente, tipo Altova XML Spy e Co. Oppure andate su questo sito, dategli in pasto l’XML e lui fa l’infer dell’XSD. Differenze: Altova rules, ma soprattutto l’infer dell’XSD crea un XSD in cui spesso vanno sistemati a mano i tipi dati (perchè viene messo tutto a xs:string).
3. Ora che avete l’XML da utilizzare e l’XSD che lo descrive, dovete usare un tool a riga di comando di Visual Studio. Si, avete sentito bene: RIGA DI COMANDO… eheh. Il tool si chiama xsd.exe e, una volta aperto il command prompt di Visual Studio, lanciate:
1. xsd nome.xsd /classes /l:CS
4. Il comando a destra(potete modificare i parametri come volete, leggete la guida di xsd) vi creerà un file (nome.cs) con tutte le classi necessarie e gli attributi necessari per mappare il vostro/vostri file XML.
5. Ora andiamo in Visual Studio, aggiungiamo il file creato e abbiamo quasi finito.

Serializzazione

Vedere che ogni microargomento di un articolo di informatica meriterebbe un libro a sè stante, è disarmante. A noi basti sapere che la serilizzazione (o deserializzazione) è il processo per cui una classe o un albero di classi viene trasformata in un flusso binario (o viceversa) per essere trasmessa su un generico stream (questo sia uno stream di rete o un file).

Quindi il processo inverso, dato un file, ne costruisce un oggetto o un albero di oggetti.

Deserializziamo l’XML con queste righe di codice:

A questo punto potete utilizzare l’oggetto esattamente come un oggetto locale, modificandone i campi, aggiungendo altri oggetti all’albero dei nodi, etc. Una volta completate le eventuali operazioni di modifica, potete salvare i cambiamenti con lo stesso procedimente, ma al contrario.

NB: tenete sempre a mente che il path del file XML deve puntare ad un percorso valido SUL DISPOSITIVO quindi, per fare i test, potere mettere i file sul file system remoto tramite explorer, dopo aver fatto il cradle del dispositivo.