Newsgroup: it.comp.lang.delphi
Titolo: componenti "data aware" e OOP

Conviene secondo voi utulizzare questo tipo di componenti in un progetto che 
voglia essere realmente orientato agli oggetti, oppure sono utili solo per 
piccoli progetti o per prototipi di applicazione?

piccoli progetti o per prototipi di applicazione?
http://bdn.borland.com/article/0,1410,28156,00.html
	Ciao
	MassimoB
 
---------------------------------
http://www.massimobeschi.it/
---------------------------------
Se tu pagare come dici tu ...
Io lavorare come dico io ...
Se tu pagare come dico io ...
Io lavorare come dici tu ...
---------------------------------


sembra interessante...dico sembra perché faccio una fatica boia a leggere 
quell'inglese! 

 tranquillamente, perché sei legato "solo" ad un OPF.
puoi segnalarmi uno di questi con cui posso utilizzare anche i componenti 
data-aware?


Eccallà.
Mancava da un pò questa domanda.
Opinione personale: dipende.
Se usi i controlli data-aware direttamente collegati a qualche query o
dataset "diretto", ovviamente sarai legato mani e piedi alla soluzione
scelta.
Qualora, invece, tu decidessi di uscrie un pò dai canoni "standard",
potresti per esempio dare un'occhiata a qualche Object Persistence 
Framework(OPF) che ti darebbe la possibilità di astrarti dal
database e concentrarti sulla logica di business.
Alcuni di essi hanno una interfaccia a dataset, quindi puoi
utilizzare - in quel contesto - i componenti data-aware abbastanza
tranquillamente, perché sei legato "solo" ad un OPF. Sposti, in
sostanza, la dipendenza ad un altro livello, guadagnandone però in
indipendenza(nei limiti dell'OPF, naturalmente) dal punto di vista
dell'architettura(a quel punto la tua form è solo un ambiente di
editing, visto che tutto il resto può essere fatto in altri modi,
inclusa la validazione).
Ciao,
Andrea

 data-aware?
Te ne segnalo 2 :-)
http://www.instantobjects.org/
http://www.techinsite.com.au/tiOPF/
Ciao,
Andrea

Andrea


 
http://www.techinsite.com.au/tiOPF/
tiOPF non è propriamente un OPF che ti consente di usare i controlli
data-aware, anzi direi il contrario. C'è un'estensione del Dataset che
consente di agganciare come sorgente un contenitore di oggetti
(tiPerObjList nel caso di tiOPF1) ma è inserita in tiOPFExtras e non
nel Core.
guastatore

 i dataset, con i Controlli DBAware mediante DataSource.
Non ho capito questa affermazione Massimo. Cosa intendi per livello
business ? E il non utilizzo di SQL ?

business ? E il non utilizzo di SQL ?
Intendo che nell'architettura 
DataSet->DataSetProvider|->ClientDataSet|->DataSource->Controlli
vedo abbastanza distinti i tre layer di analisi e
progettazione (le pipe "|" dividono i componenti nei
layer)
Data-Layer->Business-Layer->Gui-Layer
Dove sul ClientDataset avviene il calcolo, l'utilizzo o
la manipolazione dei dati spettante al livello
Business.
Tutta questa maniera di dividere i componenti in layer
viene distrutta se inseriamo una istruzione SQL (e
quindi specifica per un certo gruppo di sistemi di
persistenza dei dati) direttamente nel commandText del
ClientDataset in quanto stiamo facendo delle
assunzioni sul metodo di accesso ai dati che non
dovrebbero essere fatte al livello Business.
Ovviamente il tutto nella mia umilissima maniera di
vedere l'architettura VCL.


 vedere l'architettura VCL.
Ma certamente :-) Lo scambio di opinioni è sempre importante, imho. Lo
scenario che vedo io non è esente da problemi ovviamente.
Il primo è quello definito Impedance mismatch, ovvero la necessità di
mappare gli oggetti ad un db relazionale non è sempre semplice e
comporta una serie di problemi e adattamenti che spesso si riflettono
sulle performance.
Un altro è che la flessibilità offerta dagli OPF spesso si riflette nel
fatto che non è possibile usare tutti i componenti per Delphi che
conosciamo (questo è soprattutto vero per tiOPF, meno per
InstantObjects che ha un approccio differente).
Ancora, sviluppare un'applicazione di questo genere richiede impegno e
dedizione rigorosi, soprattutto nella fase di studio e disegno, ma
dovrebbe portare innegabili vantaggi riguardo la pulizia del codice
ottenuto, la manutenzione ecc..
ciao
-- 
guastatore
ICLDweb: 
http://www2.samatel.com/icld/

 
http://www.instantobjects.org/
Grazie.
Ho scelto IO, e lo sto provando per ora.
Ho provato un pò di cose, tra cui anche l'aggancio ai componenti db-aware.
Funziona tutto ovviamente, tuttavia ogni tanto l'utilizzo di queti 
componenti con IO mi solleva delle eccezioni del tipo Access Violation, che 
non credo proprio dipendano da me!
E' normale? dipende dal mio delphi forse non proprio ben patchato oppure dal 
framework? 

 ha scritto nel messaggio 
news:42ba97bf$0$19537$5fc...@news.tiscali.it...

Anzi no..completamente inutilizzabile.
Chiamo refreshdata su un selector per piu' di una volta mi scattano le 
eccezioni. 

guastatore


 utilizzati adeguatamente ai requisiti.
Direi di sì :-) Anche io in tutti i modi mi affido a questi strumenti,
anche se mi piace studiare e provare altre metodiche che possano
migliorare il software. Magari non sarà così ;-)
ciao
Antonio

Antonio



Capisco che il clientdataset fornisca astrazione per quanto riguarda la 
persistenza dei dati.
Non riesco invece a capire in che modo tale componente possa dettare regole 
di business.
Ad esempio voglio che quando aggiungo un articolo della spesa devo anche 
aggiornare il totale del mio carrello coerentemente. Questa potrebbe essere 
una regola di business giusto?
Ecco che vantaggi mi può dare questo componente in questo caso?

 ha scritto nel messaggio 
news:42bbcc3d$0$19529$5fc...@news.tiscali.it...

intendo nel caso vi sia un componente data-aware che mi permette la modifica 
dei dati, in che modo il ClientDataSet mi fa passare i dati per il business 
layer? 

layer? 
Il ClientDataset in se non contiene regole di business,
ma, intendevo, può essere utilizzato come un componente
facente parte del business-layer. Poi le regole di
business le introduci tu, magari negli eventi, o in
delle procedure, che richiami allo scatenarsi di certe
azioni GUI, a cui passi il ClientDataset per fare le
operazioni di business da te progettate.
Semplicemente, visto il livello di astrazione dal
sistema di reperimento dati del ClientDataset
(DataSetProvider), utilizzare tale componente nel
business-layer non inficia l'astrazione del layer
stesso dal metodo di reperimento dati implementato nel
data-layer.
Per esempio ho un Cds dei clienti nel business-layer,
lo passo ad una procedura del data-layer o lo collego
ad un DatasetProvider del data-layer, e lui me lo
carica con i dati. Poi lo stesso Cds viene utilizzato
dal business-layer che valida gli utenti o un utente
specifico contenuto. Poi il Cds viene passato ad una
procedura del GUI-layer, o collegato ad un DataSource
del GUI-layer, per l'esposizione dei dati all'utente.
