Quanti di noi non hanno almeno una volta nella vita popolato una ComboBox con record provenienti da un database? Io probabilmente questa mattina ho tagliato il traguardo della 50.000.000 query scritta a questo scopo. :-) Ma oggi, lavorando fianco a fianco con una collega, mi sono messo a fare propaganda su gestire la complessità del codice, uno degli aspetti che mi hanno affascinato nella lettura di Code Complete 2. Vi illustro lo scenario.
Supponiamo, lo ripeto, di aver a che fare con un progetto VBA (!!!), con una form ExportForm ed un oggetto FornitoreComboBox pronto per essere riempito. Supponiamo ancora di voler popolare la ComboBox (senza usare data-binding) con tutti i fornitori presenti in una ipotetica tabella sotto Oracle. Niente di più banale, direte voi.
Dichiaro una variabile SQL di tipo stringa ed assegno qualcosa del tipo: "SELECT forn_codice, forn_nome FROM fornitori". Apro un bel vecchio ADODB.Recordset, faccio un loop per ciclare tutti i records e uno alla volta riempo la ComboBox. Fin qua nulla di particolare. Adesso supponiamo che, a seguito di sviluppi o modifiche al progetto, cambino i requisiti in base ai quali riempire quella ComboBox: non bisogna far vedere agli utenti tutti i fornitori in tabella, ma solo quelli che hanno determinate caratteristiche. Queste caratteristiche coinvolgono altre 9 tabelle (non è un numero inventato, contattatemi e vi racconto), per vedere quali di questi hanno o meno un attributo, hanno avuto o meno un ordine negli ultimi 30 giorni, la segretaria che ci lavora è carina oppure no, e via dicendo. E' chiaro fin da subito che la stringa "SELECT forn_codice, forn_nome FROM fornitori" diventa un po' più complessa ed elaborata in tutti i sensi: sviluppo, debug, prestazioni, manutenzione, evoluzione nel futuro. Dobbiamo aprire un'altra strada.
Stiamo parlando di Oracle, per cui la prima cosa da fare è aprire Toad e sviluppare la mia query lì. L'IDE - che io personalmente considero bacatissimo - è più che buono per cose di questo tipo: indentazione, sintassi, debug. Scrivo la query, vado in JOIN con le altre, impongo le condizioni, uso gli indici e quant'altro. Risultato: una query che fa il suo sporco lavoro, ma lo fa in 36 righe di codice ben formattate. La domanda è: come rendo utilizzabile questa query da VB ?
Il Toad ha una features interessante: seleziono una query, clicco su Make Code e nella clipboard mi finiscono una serie di istruzioni Visual Basic che mi costruiscono una stringa che esegue la query stessa (tutto questo a suon di SQL = SQL & "..."). Una scelta potrebbe essere questa: vado in VB, incollo ed ho la stringa pronta per aprire il recordset. Ma cosa succede se trovo un bug, i criteri di selezione cambiano ancora, voglio estrarre un campo in più o in meno? La manutenzione è Infernale, con la 'I' maiuscola. E' vero che Toad ha anche la feature inversa (da VB a SQL), ma non sempre funziona, soprattutto se mi metto a modificare a mano il codice in Visual Basic, magari per sostituire magic numbers con costanti più...intelligenti e chiare.
La soluzione è usare una view. A mio avviso, manutenere codice SQL in Visual Basic (ma anche in C#, C++, Java, PHP, etc.) è davvero problematico, soprattutto se le SQL sono complesse come quella di prima. Usando una vista, sposto la complessità del codice dal linguaggio di programmazione all'engine che si occuperà di eseguirla, che è un po' meglio. Evito di avere un miliardo di righe nel mio progetto VB che non fanno altro che concatenare stringhe a volontà fino a produrre un SQL valido, ma schifosamente assurdo da leggere e da capire, con tutti quegli apici, allungando a dismisura il codice. Tornando al mio scenario, in VB adesso ho una semplice stringa "SELECT forn_codice, forn_nome FROM vista_fornitori" che non cambierà mai, perchè tutta la logica in base alla quale estrarre i fornitori interessanti è sul server, con tutti i vantaggi del caso. Se devo evolvere la query, se devo debuggarla, se devo correggerla in qualche modo, non devo rimettere mano al mio VB: correggo la vista ed il gioco è fatto.
Mi sento di aver inventato l'acqua calda stamattina, ma ci sono colleghi che insistono nel primo approccio, cioè nell'usare il Make Code del Toad per generare codice VB e poi si trovano in panne quando devono apportare qualche modifica. Quando quella modifica la deve far qualcun'altro, è ancora peggio, come è successo a me.