Ribaltamento della prospettiva nel creare applicazioni. Dal DB all'interfaccia e viceversa
Quale approccio usate nello sviluppo delle applicazioni?
Anni fa per me era un must che lo sviluppo di una nuova applicazione iniziasse dal database e su quello si iniziasse a disegnare il DAL per risalire fino all'interfaccia utente. Per questo i primi giorni erano dedicati al design e all'implementazione di un primo prototipo di database.
Quello che ottenevo era un modello basato sul "Transaction Script" o sul Table Data Gateway con i loro vantaggi e svantaggi.
A quel tempo la parte più importante dell'applicazione era il database.
Il problema di questo approccio bottom-up è che ti porta a creare una miriade di "micro-metodi" che rendono tedioso lo sviluppo degli strati soprastanti. Il classico "errore" è quello di creare tutti i metodi CRUD per ogni tabella, scoprendo poi che alcuni non servono assolutamente a nulla o obbligano gli strati superiori a conoscere la struttura del database (ad esempio devono sapere l'ordine di inserimento per non violare i costraint di Foreign Key).
L'altra sensazione di prurito era dovuta al fatto che ciò che ottenevo non era molto Object Oriented, mi limitavo solamente ad usare l'ereditarietà per "riciclare" un po' di codice dummy del data access layer (tipicamente legato alla gestione della connessione e degli errori).
Nel 2003 ho letto un libro che ha cambiato la vita a molti dev "patterns of enterprise architecture".
Dopo averlo letto (anche un paio di volte) ho capito che qualcosa nel mio modo di progettare e sviluppare applicazioni doveva essere migliorato: ho scoperto il Domain Model.
Quindi iniziai a pensare le applicazioni partendo dal modello ad oggetti del dominio applicativo e una volta pronto il DM mi occupavo dello sviluppo del database e della user interface parallelamente completando di volta in volta una fetta di applicazione.
In quel periodo la parte più importante dell'applicazione era il DM.
Ora mi trovo in un periodo di transizione e mi viene naturale iniziare a sviluppare le applicazioni partendo dall'interfaccia utente .
Mi rendo conto che la UI (spesso denigrata dai noi dev) sia per l'utente finale la parte più importante, non tanto dal punto di vista dell'estetica (anche), ma piuttosto dell'usabilità e del modo in cui si presentano le informazioni sullo schermo.
La prima cosa che faccio è disegnare (spesso su carta) le bozze di quella che diventerà la mia interfaccia utente pensando alle interazioni, al modo di visualizzare e leggere i dati sulle varie form (o pagine).
Dall'interfaccia scendo verso il basso passando per il domain model e arrivando al database.
Il problema nel partire dal DM è che il suo disegno spesso vincola il disegno dell'interfaccia utente e secondo me questo è un errore perché il modo di interagire con l'utente deve essere il più naturale possibile e non deve essere vincolato a qualcosa che costituisce l'infrastruttura della nostra applicazione.
Perciò partendo dalla UI sono libero di inventarmi tutti i meccanismi che servono per massimizzare l'usabilità.
Non è ancora una metodologia collaudata, la sto provando su alcune applicazioni che sto realizzando in questo periodo. Per ora posso solo constatare che il mock-up su carta permette all'utente di chiarirsi le idee su cosa vuole e a me fornisce un punto di partenza per una funzionalità o una nuova storia. Il DM nasce in modo più naturale guidato dalla funzionalità da implementare e ad ogni nuovo elemento della user interface si arricchisce di dettagli e relazioni.
Questo vuol dire che il DM e il DB sono meno importanti? Assolutamente no.
Metodologie
Design