"Sostituzione di componenti non visivi con codice" una collaudata tecnica di ottimizzazione in Delphi 7. Principalmente per quanto riguarda l'accesso al database.Sostituzione di componenti non visivi con il codice
Non si tratta di essere un componente o non un componente. Se si tratta dell'accesso al database, BDE è estremamente lento, quindi cambiarlo per sth è una buona mossa.
A proposito: l'ottimizzazione non riguarda le "tecniche collaudate": si tratta di identificare un problema e risolverlo. Se il problema si verifica come accesso db lento, questo è ciò che devi modificare.
Per quanto riguarda l'accesso al database Sto usando gli oggetti ado e non bde perché ho più familiarità con ado. –
Non vedo come un set di dati basato su modulo/query/tabella/ecc., Sarebbe più veloce o più lento di quello creato nel codice. Tuttavia, mi piace metterli in codice in quanto è più facile da mantenere. Ho visto schermate con SQL incorporato in un componente, e quindi è stato sovrascritto nel codice. Quindi devo interrompere e indagare per determinare quale SQL è effettivamente in vigore. A volte l'SQL nel modulo è buono, a volte viene usato per un po 'e poi trumpato dal codice, a volte non è mai attivo e l'SQL viene troncato nella formcreate. Quindi devo determinare se questo è di progettazione, o semplicemente avanzi sciatti. Inoltre, è facile perdere le modifiche SQL nelle revisioni del codice se sono in .DFM e non in .PAS. Ad esempio, non guardo sempre a .DFM perché non sono interessato a modificare la didascalia di un'etichetta o a spostare un pulsante.
Così mentre è bello per la prototipazione, quando si tratta di codice di produzione, è meglio avere tutta la logica del database (SQL, tabelle e definizioni dei campi) nel file .pas.
Aggiornamento: ho finalmente dato CnPack una prova. Tra le dozzine di gadget, c'è un brillante strumento chiamato "converti componenti selezionati in codice". Creazione guidata modulo di progettazione | Altro ... | Convertire i componenti selezionati nel codice. Fa tutto per te.
Questo è quello che sto pensando di fare. Il codice su cui sto lavorando in questo momento è ereditario e non quello che ho creato. Quindi penso che ci vorrà del tempo per spostare tutta la logica sql dal file .dfm al file .pas –
@Vinayek - non te ne pentirai. Verificare inoltre che tutte le tabelle, i connettori del database, le sessioni e così via siano impostati come inattivi. Se trovi qualcosa che è attivo, fai attenzione al codice per assicurarti di aprire tu stesso le connessioni. Ad esempio, potresti avere delle forme che "diventano fortunate" perché il database effettivamente risiede dove l'autore originale pensava che sarebbe. –
Grazie per il consiglio. Ho appena iniziato a riscrivere la parte di accesso ai dati del codice. I componenti della finestra di dialogo –
Il sito Web di cui si cita parla della sostituzione di una finestra di dialogo componente con codice che visualizza la finestra di dialogo senza l'uso di alcun componente. L'alternativa è scrivere un paio di righe di codice per impostare e visualizzare una finestra di dialogo ogni volta che ne hai bisogno e saltare il componente del tutto. Tuttavia, non è davvero un'ottimizzazione della velocità o della dimensione. Non è un ottimizzazione della velocità poiché il tuo codice farebbe esattamente ciò che un componente avrebbe comunque fatto, e non è un'ottimizzazione delle dimensioni perché lo spazio occupato da un componente in un programma è trascurabile.
I componenti del database non sono così facilmente sostituibili come componenti della finestra di dialogo. Quasi in Delphi è stato progettato tutto il per utilizzare i discendenti dei componenti standard del database. Se non si utilizzano i componenti, non si utilizzerà affatto alcuna delle funzionalità di database di Delphi. Puoi utilizzare le API native delle librerie di database, se lo desideri, ma penso che sarebbe sciocco se il tuo obiettivo è davvero l'ottimizzazione e non hai identificato i componenti come l'origine del comportamento non ottimale del tuo programma. Considerare quanto tempo e impegno ci vorrebbe per riscrivere il programma senza i componenti del database.
sono solo citati come esempio. Se viene creato un oggetto della stessa classe del componente, saranno disponibili tutte le funzionalità del database di Delphi. Per favore correggimi Se ho torto assumendo la suddetta cosa. –
Hai ragione, ma confuso. Pensi che il consiglio fosse di istanziare manualmente i componenti invece di lasciarli su un modulo o un modulo dati. Per i componenti del database, questo non ti dà alcun vantaggio. In realtà, il consiglio era di non usare i componenti * affatto *. Per i componenti del database, questa è una pessima idea. –
Grazie per il consiglio –
Generalmente no. Non c'è nessun sovraccarico nell'utilizzo di un componente non visivo. Viene creato molto rapidamente e funziona in runtime esattamente alla stessa velocità di uno "creato nel codice".
Se il componente non visivo viene sostituito dal codice, alcune componenti non visive che sono state utilizzate solo in una singola procedura verranno rimosse dalla memoria una volta che la procedura ha terminato l'esecuzione. Sto parlando principalmente di componenti per l'accesso ai dati. –
Potete fornire riferimenti ai blog o qualsiasi altra cosa lo raccomandi? Non ne ho mai sentito parlare prima (il che non significa nulla, ovviamente :) – Blorgbeard
vedi punto n. 8 in http://delphi.about.com/od/objectpascalide/a/speedsize.htm –
btw, gexperts è un ottimo componente aggiuntivo che converte i componenti in codice. –