Newsgroup: it.comp.lang.delphi
Titolo: Utilizzo OPF - dubbi

Ben ritrovati,
ma torno subito ad un già vecchio ed annoso problema iniziato in una
precedente discussione (parzialmente scomparsa dal mio 'GuardaFuori
LettoreDiNotizie', ...perchè??) :
Ho seguito il suggerimento di Guastatore scaricando e studiando, tra gli
altri, la documentazione ed il codice di esempio (Appointment) di Philip
Brown, ho creato un nuovo progetto sulla base di quel codice ed ho
realizzato una struttura che gestisse l'archivio Libri, ossia le semplici
operazioni di Inserimento/Modifica/Cancellazione/Ricerca. Ho lasciato
perdere un attimo l'archivio studenti perchè ho pensato meno centrale
rispetto al problema, ma soprattutto meno popoloso.
Per provarne la bontà del lavoro fatto ho inserito 4000 records fasulli
generati tramite un ciclo For. Sono rimasto fortemente deluso dalle
prestazioni di ricerca e visualizzazione realizzate da questo codice: Per
visualizzare in una ListView tutti i records ha impiegato 3min e 42sec
(!!!).
Che dire... con il codice prodotto da me ...ignorante in materia... la
visualizzazione avviene in circa 2sec e mezzo, non so se!!!
Mi sono spulciato il codice ed ho scoperto l'arcano:
praticamente il framework, pur avendo già tutto in memoria, in quanto nel
momento in cui apro una query, di fatto, ho già tutto quel che mi serve
sapere a disposizione, nel riversare il risultato della query nella TList
effettua, tramite un ciclo while, una Select per ogni record passato in
rassegna, per fare cosa? per rileggere il contenuto dei campi del tale
record che già ha.
Ma non vi sembra eccessivamente macchinoso?
Tra l'altro ho sbirciato un po' di codice in giro ed un po' tutti gli OPF
caricano all'interno di una Lista (TObjectList, TContainer, TList, ...) il
risultato delle proprie query. Perchè? Se io apro un query contenente un
insieme di record corrispondenti ad un dato criterio, non è più utile e
veloce sfruttare l'oggetto che ha già caricato tutto quel che serve (TQuery
di turno) e sfruttare i suoi metodi per navigare tra i record, piuttosto che
ciclare sui record per inserirli in una lista? Tanto a quanto mi è sembrato
di capire, se dovessi cambiare la modalità di accesso ai dati, ossia se
dovessi cambiare la base di dati, comunque dovrei cambiare gli oggetti
utilizzati per l'accesso fisico ai dati e di conseguenza tutti gli oggetti
che s'interfacciano direttamente ad essi.
Cos'ho detto? ...non so se mi rendo conto di quello che dico? ;P
Ciao.

Cos'ho detto? ...non so se mi rendo conto di quello che dico? ;P
Guarda, non ne capisco una cippa di OPF, ma il tuo post mi sembra molto ben
scritto e validamente argomentato :-)
Ora, la parola a chi ne sa veramente... :D
Ciao
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

 Ma non vi sembra eccessivamente macchinoso?
Ciao,
partendo dallo stesso esempio ho modificato un po' il framework in modo 
da eseguire il fill di ogni pdobject direttamente da dataset ...
per capirci una roba di questo tipo:
procedure TBOList.GetList(ADataset: TDataset; AClear: boolean=true);
var
   mBoObject: TBOObject;
begin
   if AClear then
     ClearList;
   ADataset.First;
   while not ADataset.Eof do
   begin
     mBoObject := CreateABOClass(copy(ClassName, 1,length(ClassName)-4));
     mBoObject.DMObject := FDMObject;
     mBoObject.Mapper.PopulateObjectFromDataset(ADataset);
     Add(mBoObject);
     ADataset.Next;
   end;
end;
altrimenti e' veramente lento ...
Ciao

 da eseguire il fill di ogni pdobject direttamente da dataset ...
Ok, più o meno ci siamo, nel senso che comunque rimane la domanda: perchè
ricorrere ad una lista, perchè riversare da qualche altra parte qualcosa che
già ho così come mi può servire nella stragrande maggioranza dei casi.
Non sarebbe più utile costruire un wrapper sul TQuery (TIBQuery, TADOQuery,
ecc.) anzichè passare i risultati ad una simil-TList e lavorare con essa?

 Cos'ho detto? ...non so se mi rendo conto di quello che dico? ;P
Nella tua applicazione è così perché probabilmente non hai separato le
classi dallo strato di persistenza. Gli altri framework, al contrario,
consentono proprio di cambiare il database sottostante senza problemi,
l'applicazione continua a funzionare.
Nel caso di tiOPF, per esempio, puoi farlo addirittura a runtime, senza
chiudere la tua applicazione. Ripeto, ci sono vantaggi e svantaggi in
tutto. Sempre in tiOPF, se per il mapping usi l'autogenerazione del
codice SQL allora hai davvero pochi problemi e massima flessibilità
dato che riesce a mappare anche database XML, ma hai delle
penalizzazioni nelle performance.
Se invece usi codificare l'SQL in modo hardcoded allora potresti
incappare in problemi di compatibilità tra i vari SQL dei DB ma avere
delle performance eccellenti. Considera che una volta creati e caricati
gli oggetti in memoria, le ricerche sono davvero molto veloci.
ciao
guastatore

Francesco Poli ha scritto:

come ha gia' accennato Guastatore, soprattutto per mantenere separato il 
livello di accesso ai dati.
In questo modo i dati possono provenire da un file di testo, da un db, o 
da qualsivoglia fonte dati... sara' sufficiente creare un apposito 
oggetto che si occupi dell'accesso ai dati.
Mentre wrappando un TQuery o similare sei vincolato al database ...
Ciao