VueLityx© DataModule e DataSource in Vue.js

VueLityx© DataModule e DataSource in Vue.js 

POSTED BY GIULIANO PAGNINI, 28 AGO 2026 

Un DataSource per governarli tutti: come abbiamo portato il DataModule di RadStudio dentro un'app Vue.js

Chi viene dal mondo Delphi©/C++Builder© lo conosce bene: il DataModule. Quel posto, spesso l'unico in tutto il progetto, dove sai di trovare ogni TDataSource, ogni TTable, ogni TQuery dell'applicazione. Non devi cercarlo form per form. Non devi capire quale schermata "possiede" quale connessione. È lì, centralizzato, e ogni form ci si aggancia semplicemente impostando una proprietà.

Chi invece viene dal mondo frontend moderno conosce fin troppo bene il problema opposto: dati sparsi ovunque. Una fetch qui, uno state locale là, una prop passata attraverso quattro livelli di componenti solo per far arrivare un valore da un punto A a un punto B. Funziona, finché il progetto è piccolo. Poi smette di funzionare.

Con l'ultimo aggiornamento di VueLityX abbiamo deciso di prendere il meglio dei due mondi — e il risultato ci sta piacendo più di quanto immaginassimo.

Il problema: ogni vista, il suo piccolo regno

Fino a poco fa, ogni schermata della nostra suite gestionale dichiarava i propri dati per conto suo. La vista Anagrafe Comuni caricava i suoi comuni. La vista Portfolio caricava i suoi investimenti. Funzionava, ma con due conseguenze scomode:

• Duplicazione: la stessa logica di caricamento, ripetuta vista dopo vista.
• Nessuna vista d'insieme: per sapere "quali fonti dati usa questa applicazione" dovevi aprire ogni singolo file e cercare.

Se hai mai lavorato su un progetto Delphi©/C++Builder© senza DataModule — con le TTable/TQuery sparse form per form — sai esattamente di cosa parliamo. È lo stesso identico dolore, solo in salsa JavaScript.

La soluzione: un TDataModule, per davvero

Abbiamo introdotto un componente TDataModule, montato una sola volta all'avvio dell'applicazione — non dentro una vista specifica, ma a livello di app, esattamente come un vero DataModule Delphi©/C++Builder© non appartiene a nessuna form in particolare.

Al suo interno, un elenco centralizzato di tutte le TDataSource disponibili: cosa sono, da dove arrivano i dati, come vanno filtrati e ordinati. Un solo posto. Una sola fonte di verità.

Le viste non dichiarano più nulla: si limitano a referenziare un id.

<TNavigator datasource="dsComuni" />
<TDataGrid datasource="dsComuni" storage-id="anagrafe-comuni" />

Esattamente come in Delphi©/C++Builder© imposti DataSource := DataModule1.dsComuni su una TDBGrid senza doverla ricreare, qui basta il nome. Il resto — caricamento, cache, stato — vive nel DataModule, condiviso e coerente ovunque venga usato.

Il vero salto: un DataSource che non sa (né gli importa) da dove vengono i dati

Qui arriva la parte che ci entusiasma di più. Ogni TDataSource è agnostica rispetto all'origine. La stessa identica interfaccia — stessi metodi di navigazione, stesso ciclo Insert/Edit/Post/Cancel, stessa integrazione con griglie e form — funziona indifferentemente su:

• Array locali in memoria, per prototipare in un attimo
• File JSON statici, per dati semi-fissi
• API REST, per collegarsi a un vero backend
• IndexedDB, per persistenza locale offline-first

Cambiare l'origine di un datasource — da un mock locale a un'API REST vera — non richiede toccare una sola riga delle viste che lo usano. Griglie, form, navigatori: tutti continuano a funzionare, perché parlano con l'astrazione, mai con l'origine concreta.

È la stessa filosofia dei TDataSet di Delphi©/CBuilder© (TTable, TQuery, TClientDataSet...) applicata al web: il codice applicativo non dovrebbe mai sapere — né interessarsene — se dietro c'è un file, un database o una chiamata di rete.

Ispezionabile, modificabile, senza scrivere una riga di codice

E qui il cerchio si chiude con l'altro pilastro di VueLityX: l'Object Inspector nativo. Ogni TDataSource registrata nel DataModule è visibile, in tempo reale, dal nostro tool di ispezione C++Builder — proprietà, stato, record caricati, tutto a colpo d'occhio, proprio come ispezioneresti un componente Delphi/C++Builder a design-time.

Vuoi cambiare l'origine dati di una griglia mentre l'app gira? Selezioni il componente, apri il Wizard, scegli la nuova fonte. Nessun redeploy. Nessuna riga di codice.

Perché conta, davvero

Non è (solo) nostalgia per chi viene da Delphi©/C++Builder©. È una scelta architetturale che paga concretamente:

• Manutenzione più semplice: un solo posto dove capire "che dati usa questa app".
• Refactoring senza paura: cambiare fonte dati non tocca la UI.
• Sviluppo più veloce: prototipa con un array locale, passa a REST quando il backend è pronto, senza riscrivere nulla.
• Debug immediato: ispeziona ogni datasource dal vivo, senza console.log sparsi ovunque.

Il DataModule non è mai stato "solo" una comodità per pigri. Era — ed è — un modo maturo di pensare all'architettura dei dati. Portarlo su Vue.js, con tutta la reattività e la flessibilità del frontend moderno, è esattamente il tipo di ponte che VueLityX vuole costruire tra due mondi che, a conti fatti, hanno sempre avuto più cose in comune di quanto sembrasse.

#Delphi #VueJS #CPPBuilder #LowCode #WebDevelopment #VueLityX