Strategie per la conversione di applicazioni BDE verso dbExpress tramite InstantBDExpress

(C) 2005-2015 Ethea

Questo articolo riassume le tecniche che si possono usare per la conversione di applicazioni BDE esistenti verso dbX tramite InstantBDExpress. Queste tecniche rappresentano un distillato della nostra esperienza nella conversione di applicazioni per i nostri clienti, ma non sono che la punta dell'iceberg. Non esitate ad interpellarci per qualunque chiarimento.

Ridurre al minimo le modifiche al codice

Con questo approccio si tenta di convertire l'applicazione senza modifiche al codice, ovvero senza modificare i nomi dei componenti e le clausole uses delle unit. Questa operazione di restyling , in effetti, può essere svolta in modo quasi del tutto automatico (come vedremo nelle prossime sezioni), ma evitandola del tutto si guadagna la possibilità di iniziare le prove quasi immediatamente. Il trucco, in questo caso, consiste nell'avere un insieme di componenti con la stessa interfaccia (si intende metodi e proprietà pubblici) di quelli BDE, e con gli stessi nomi. La prima parte del requisito è soddisfatta dai componenti IBDX, e la seconda da una cosiddetta unit interposer. Si tratta di una unit che definisce classi derivate da tutte le classi IBDX, usando i nomi delle equivalenti classi BDE. Quando l'applicazione, a run time, userà questa unit, starà usando IBDX senza modifiche.

Quindi, come si crea questa unit interposer? Diciamo che non è necessario farlo, perché ne trovate una di esempio fornita con IBDX. La unit IBDXInterposer.pas, che trovate nella cartella samples di IBDX, può essere presa come esempio e punto di partenza, e personalizzata per adattarla alle esigenze specifiche. Questi adattamenti possono essere molti se l'applicazione è complessa, o se si sta cambiando contemporaneamente anche il tipo di database (non è consigliabile cambiare tipo di database e tecnologia di accesso ai dati contemporaneamente, anche se è possibile).

Per fare in modo che il progetto usi la unit interposer, si può applicare una delle tecniche seguenti:

  1. Si dà nome DBTables alla unit, e la si aggiunge al progetto (o la si salva nella cartella del progetto). Perché questa tecnica funzioni, occorre che l'applicazione non sia compilata con i package run time. Questa tecnica è spesso sufficiente per applicazioni semplici.
  2. Si assegna alla unit un nome qualsiasi, e si definisce un alias a livello di progetto. Un alias fa in modo che tutti i riferimenti ad una certa unit all'interno di un progetto siano tradotti in riferimenti ad un'altra unit in fase di compilazione. L'alias, che va impostato attraverso la finestra Project Options di Delphi, deve far corrispondere a DBTables la nuova unit interposer. Ad esempio: DBTables=MyDBTablesInterposer.
  3. Si dà alla unit un nome a piacere e si fa in modo che tale nome compaia in tutte le clausole uses in cui compare DBTables, e che in tali clausole sia elencata dopo DBTables. Questo è un po' rischioso e richiede molta cura.

Se il vostro progetto usa le unit DbiProcs, DbiTypes, DbiErrs o BDE, significa che fa uso della API di basso livello del BDE. InstantBDExpress non è progettato per emulare questa API, per cui le parti di codice che ne fanno uso dovranno essere analizzate e riviste.

Se, una volta predisposta la unit interposer, l'applicazione è compilabile, siamo a buon punto: significa che si può iniziare con le prove. Diversamente, i problemi andranno analizzati e risolti caso per caso.

Per poter cominciare le prove, occorre definire un alias IBDX corrispondente all'alias BDE usato dall'applicazione. Per fare ciò, potete usare l'IBDX Administrator come descritto in Convertire MastApp.

E se la mia applicazione usa componenti custom derivati da TTable/TQuery?

Se avete creato vostre personalizzazioni dei componenti dataset e field del BDE, la cosa migliore che potete fare e modificarli perché siano ereditati dai componenti IBDX. L'interfaccia protetta del BDE, a differenza di quella pubblica, non è emulata in maniera completa da IBDX, ma non dovreste avere problemi (a meno che i vostri componenti facciano cose particolarmente complesse). Volendo, è possibile creare uno strato di indirezione tra i componenti IBDX e i vostri; tale strato ospiterà le eventuali personalizzazioni necessarie per avvicinare dbExpress al vostro codice applicativo.

In questo scenario l'applicazione inizia ad usare IBDX, ma lo fa attraverso i vostri componenti custom.

Saltare il fosso: cambiare i nomi dei componenti

Se l'approccio della unit interposer vi suona un po' come un trucco, è perché in qualche misura lo è. Il vantaggio principale di tale tecnica è che permette di iniziare le prove molto presto, in ciò aiutando a stimare la fattibilità del progetto di conversione.

Un approccio alternativo consiste nello sviluppo di una unit simile a quella interposer, ma con nomi diversi per le classi. Questo implica che il codice applicativo deve essere modificato per cambiare tutti i riferimenti a unit e classi BDE in riferimenti alla nuova unit e alle classi in essa definite. Fortunatamente, questo si può fare in maniera quasi del tutto automatica tramite operazioni di ricerca & sostituzione multi-file sui sorgenti. Per questo noi consigliamo l'ottimo strumento gratuito GReplace). Questa è anche l'opzione migliore nel caso in cui la vostra applicazione faccia uso di componenti custom derivati da quelli BDE, come visto nella sezione precedente.

Volendo, si possono cambiare i riferimenti ai componenti BDE in riferimenti diretti ai componenti IBDX; fare ciò è molto semplice e permette di lavorare conb IBDX a design time. Tuttavia, noi preferiamo di solito uno degli altri approcci, che lasciano maggiore spazio per le personalizzazioni.

Provare l'applicazione

Una volta verificato che l'applicazione si può compilare ed eseguire con IBDX, iniziano le prove per stabilire cosa funziona e cosa no. È a questo punto che inizia il lavoro di conversione vero e proprio. A seconda delle tecniche usate nell'applicazione, troverete di aver bisogno di applicare modifiche più o meno pesanti per farla funzionare in maniera accettabile in ambiente Client/Server. Tra le aree in cui più frequentemente si incontrano problemi segnaliamo:

Questi problemi si risolvono caso per caso, sfruttando la propria esperienza e il supporto di altri utenti IBDX o di Ethea.

Reperire altra documentazione e segnalare anomalie

Dato che lo scopo dichiarato dei componenti IBDX è quello di riprodurre il più possibile fedelmente l'interfaccia e il comportamento dei componenti BDE, la documentazione sul loro uso è a tutti gli effetti la documentazione dei componenti BDE fornita con Delphi. In caso vi imbattiate in discrepanze, segnalatecele in modo che possiamo porvi rimedio al più presto, o suggerire vie alternative.