Newsgroup: it.comp.lang.delphi
Titolo: Bold

Qualcuno ha info su bold?
Su borland cosi di fretta non trovo alcun link diretto.
E il dominio è in vendita....
Ho visto il tiOpf e volevo farmi una idea delle differenze tra questi 2 
prodotti.
Bye
A

 2 prodotti.
Bold è diventato ECO nella nuova suite per .NET di Borland in quanto la
Bold è stata acquistata da Borland. Il codice mi sembra sia staoto
rivisto ma poggia molto sul codice di Bold.
Non ho mai usato Bold quindi non posso dirti le differenze con tiOPF. 
Quest'ultimo è un ottimo OPF opensource, supporta la persistenza degli
oggetti a molti db. Consente il mapping degli oggetti ai db relazionali
tramite hard-code nei visitors della tua applicazione, tramite tiSQL
Manager ovvero un'applicazione di supporto per la creazione di
statement SQL e tramite auto generazione di SQL dopo la registrazione
dei mapping (obbligatoria nel caso in cui la persistenza debba avvenire
su XML); anche se quest'ultima è necessariamente meno efficiente della
prima porta ovviamente ad un'astrazione maggiore tra i business objects
e la loro persistenza.
Il framework non supporta i cursori ed i record per cui ci sono dei
problemi ad usarlo con i tools più usati di reportistica e anche con i
controlli visuali tipici dei db (DbEdit, DbGrid e similari). Nel
pacchetto ci sono tuttavia degli Extras, come ad esempio un Dataset che
in grado di leggere gli oggetti del framework e quindi in grado di
consentire l'uso degli strumenti visuali e di reporting che attingono
dai dataset.
La documentazione non è eccellente anche se la mailing list è molto
attiva e ci sono degli ottimi programmatori in grado di darti una mano.
In mailing list si sta parlando anche del futuro di tiOPF data l'uscita
di Delphi8 per .NET . L'autore e gli altri che partecipano al progetto
opensource non sono ancora in grado di dire se converrà migrare tiOPF a
.NET data l'intrinseca difficoltà (il framework fa un uso spinto
dell'RTTI attuale di Delphi) oppure abbandonare il progetto in favore
di ECO che anche se è molto più caro.
Alcuni proponevano almeno una fusione della parte visuale di
InstanObjects in tiOPF che è carente dal punto di vista
dell'interfaccia utente per la modellazione, ma se ne sta solo
parlando. Penso sia difficile che si realizzi.
Altre informazioni le puoi richiedere eventualmente scrivendo una mail
alla mailing list dopo esserti iscritto a 
www.techinsite.com.au
 .
Ciao
Antonio Sanguigni

Ho visto molte delle cose che hai descritto di tiOpf.
Il mio dubbio è se bold fa qualcosa in +.
Ho visto il modello eco sulla trial di c#builder e, imho, ha 2 grosse 
limitazioni:
1) usa sql ansi92.
2) non è previsto il reverse engeneering di un db gia esistente per la 
creazione di un modello eco.
Quel che mi lascia perplesso di tiOpf è che se devo lanciare una stored 
procedure devo mettere da parte tiOpf e scendere ad un livello + basso 
usando direttamente dbx|ibx/ado, o no?
Nel caso una app usa un db in 2 modi diversi, e 'sta cosa mi sembra un 
po brutta.
Oppure, leggendo il pdf di tiOpf mi è sfuggito qualcosa?
In sintesi, se devo lanciare una stored procedure per popolare una 
tabella temporanea da usare come fonte dati per un report o simile, 
posso o no passare x tiOpf o Bold/eco?
Grazie x la risposta
A

 posso o no passare x tiOpf o Bold/eco?
Lo puoi fare, ma non è consigliabile usare le stored proc, come hai
intuito, proprio per non mischiare i due modelli. Probabilmente sarebbe
meglio architettare l'applicazione per avere uno strato in più
piuttosto che svilupparla come client/server.
Antonio

 linea teorica.
A dire il vero, cosi su 2 piedi 'sta cosa non mi piace... Devo capire 
meglio..
Riguardo il cambio di db, considerando il fatto che eco usa sql standard 
e che non sembra corretto usare stored procedure, mi chiedo a cosa serve 
un sql potente come quello di oracle che di fatto non verrebbe mai usato.
A quel punto, a prescindere dalle ottimizzazioni lato server, un db vale 
l'altro....
senza contare che mi si costringe a lavorare in modo distribuito per 
estrarre la logica dal db e metterla nel codice, pur se autogenerato....
Questo è in controtendenza rispetto al "pensiero corrente" che spinge a 
mettere la logica nel db.
Metto in lista x il 3 febbraio...;)
tnx
A

 la logica nel db.
Secondo me il "pensiero corrente" dipende da come intendi sviluppare le
tue applicazioni. Ogni metodo presenta vantaggi e svantaggi. Sviluppare
un'applicazione completamente ad oggetti non consente di spingere la
logica nel db, non usa i dataset classici in maniera tipica (alcuni non
li usano affatto).


> > Metto in lista x il 3 febbraio...;)
Cosa c'è il 3 febbraio ;-) ?
Mi è scappato un alt-invio di troppo ed è partito il post :-(
Ciao
Antonio

Cosa c'è il 3 febbraio ;-) ?
Alberto sta preparando il suo intervento alla conferenza su octane che si
terra' a Milano il 3 Febbraio.
E' stato messo prima del relatore di Microsoft.
-- 
Morde. 
(
mo...@despammed.com
)

 E' stato messo prima del relatore di Microsoft.
E' vero o stai scherzando ? ;-)
Ciao
Antonio

 tue applicazioni. 
giusto
A

 appunto le stored procedure.
Certo, le stored proc sono una gran cosa e consentono un notevole
risparmio del traffico di rete. Proprio per questo in genere
progettando un'applicazione di BO, in genere, si preferiscono i tre
strati. Ci sono delle classi che si occupano di fare ciò che deleghi al
db attraverso le stored proc.
Considera ovviamente che i framework OPF mettono a disposizione delle
classi Proxy che consentono di recuperare dal db solamente le
informazioni minime e che solo successivamente, alla richiesta
dell'utente, l'oggetto verrà caricato interamente.
Ambler sostiene che con i tre strati un'applicazione BO è più
efficiente di una che poggia la logica sul db.
Ovviamente poi c'è l'annosa questione dei controlli dbaware difficili
da controllare nel traffico di rete; tramite lo sviluppo di
un'applicazione BO gli oggetti te li carichi in memoria dopo averli
recuperati (usando proxy e limitando il numero secondo approcci
variabili) per cui hai una velocità maggiore nello scorrere li griglie
ecc..
Antonio

 da controllare nel traffico di rete;
gia messi da parte ;))
A

 Sorry, non so chi è questo padreterno
http://www.ambysoft.com/
Tu cosa hai scritto sull'argomento ?

Tnx, andrea.
vado a vedere al link cosa trovo.
Il termine "padreterno" non era in senso ironico.
A

 O COSA?
Parlavamo di efficienza intesa come prestazioni. Citavo quanto aveva
riportato sul volume Object Applications that work. ;-)
Ciao
Antonio

 riportato sul volume Object Applications that work. ;-)
Devo approfondire 'sta cosa.
Ma intanto l'archiettura come sarebbe?
Una app che racchiude tutto che dialoga con il db come ujna normale 
applicazione c/s oppure distribuita, basata su almeno 3 livelli?
Azz, sta discussione si fa molto interessante, almeno x me!
6 veramente un "guastatore", sai? In senso buono, dico.... ;)
Tnx.
A

 6 veramente un "guastatore", sai? In senso buono, dico.... ;)
Anche a me piace molto la piega, devo essere sincero.
Ti ringrazio molto del complimento ;-) Mi sa che sto nick prima o poi
lo devo cambiare :-))
Ciao
Antonio

 livello Presentation (la GUI) e il db.
sempre 'sta storia di avere + 2 di livelli......
Non ho ancora trovato un qualcosa che mi ispiri fiducia x questo 
particolare ambito...
Un amico filo-microsoft ha usato MTS è sta ancora bestemmiando....
Se vuoi realizzare una cosa del genere, ora, non credo vi siano molte 
alternative ai web service....
xche cambiare il nick? E' simpatico....;)
Mii, che th mitico!!!! :)
A

 alternative ai web service....
Sì, so che sono strumenti complessi da usare. Alternativamente si
potrebbe usare CORBA.
Tuttavia, come hai sottolineato, la tendenza attuale non porta verso
gli oggetti distribuiti quanto verso architetture orientate ai servizi
(SOA). Indigo va oltretutto nel senso praticamente opposto con la
definizione di schemi e trasporti XML per l'esecuzione remota di
funzioni e procedure. Se hai 38 minuti di tempo è davvero interessante
ascoltare un'intervista a Don Box a questo link:
http://www.theserverside.net/talks/index.aspx
Ciao
Antonio

 (SOA). 
Quindi, questi 3 livelli:
 > 1. Interface classes
 > 2. Business Objects Model
 > 3. Persistence Classes
sarebbero:
una o +  app, anche di tipo diverso (livello1) che usano un "servizio" 
BOM (livello2) che usa a sua volta un "servizio" per la persistenza....
Diciamo che...
1) mettere la BOM in una gerarchia di classi *potrebbe* essere + 
semplice che metterla in un db.....
2) non si sa se conviene usare + di 2 livelli
3) volendoli usare le tecnologie disponibili *funzionanti* e non 
oboslete* non sono molte
4) non è detto che si debba usare *sempre* lo stesso modello di 
applicazione.
come sono infelice.... :(
A

 come sono infelice.... :(
E perché mai ? ;-) Le scelte che hai a disposizione sono molte. Occorre
solo vedere la più adatta e partire con il piede giusto.
Ciao
Antonio

 solo vedere la più adatta e partire con il piede giusto.
1) logica sul db o nel codice?
Se la metto sul db *potrei* non avvertire l'esigenza di + di 2 livelli.
Se la metto nel codice, usare solo 2 livelli sarebbe ridondante
Ad esempio, se volessi dare la visibilità dei dati ad un client win32 ed 
ad una pagina web, la BOM andrebbe replicata nel client win32 e in 
eventuali moduli usati dal web server
2) Qualora scegliessi di mettere la logica nel codice e usare una 
archiettura a 3 livelli, che kakkio uso? com/dcom, no. webservices? 
potrebbero essere molto lenti x una app non web
Continuo a essere infelice, sob!!
A