Newsgroup: it.comp.lang.visual-basic
Titolo: approccio per passare un oggetto in una applicazione a tre layer [lungo]

Ciao a tutti
Vorrei un consiglio da parte vostra sul migliore approccio per
realizzare 
il come passare un oggetto che ne deriva da un altro in una
applicazione a tre layer.
 
Cerco di spiegarmi
Ho una applicazione che dopo la maschera di login memorizza in un
oggetto i dati dell'utente
esempio in pseudo codice
Classe Utente
	property Cognome
	property Nome
	property IndirizzoIP
	...
End Class
 
quando l'utente fa delle operazioni io vorrei memorizzare quello che
fa su una tabella di log
Class Log
	property Cognome
	property IndirizzoIP
	property OperazioneLog
	property DataOperazione
	...
End Class
 
Il primo problema che mi si presenta è questo:
Cognome e IndirizzoIP stanno nella classe Utente
Io pensavo di chiamare la classe Log richiamando la classe Utente in
questo modo
Class Log
	property InfoUtente as Utente
	property Cognome
	property IndirizzoIP
	property OperazioneLog
	property DataOperazione
	...
End Class
 
dim aLog as new Log
aLog.InfoUtente=Utente
alog.Cognome = InfoUtente.Cognome
alog.IndirizzoIP = InfoUtente.IndirizzoIP
aLog.OperazioneLog = "XX"
 
è corretto?
 
secondo problema:
il metodo di salvataggio del log dove lo metto?
considerando che tutte le classi stanno tutte in un MODEL 
e tutti gli oggetti che interagiscono con il database stanno in un
DATALAYER
pensavo di mettere  il metodo SaveLOG nel DATALAYER però a questo
punto devo passarmi un'altra istanza del log
 
Qualcosa del tipo
Public Class LogDatabase
	Property myLOG As Log 
  Sub WriteLog()
		'richiamo tutte le proprietà dalla myLOG
		'salvo
  End Sub
End Class
 
 
oppure metto il metodo WriteLog direttamente nella classe Log?
(questo mi sembra sbagliato)
 
 
 
Insomma sto nella confusione più completa.
 
Grazie
Simona
 
 
 


 
brrr...no...active recordo no :-)
 
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

brrr...no...active recordo no :-)
questa non l'ho capita .... 
 

 questa non l'ho capita ....
 
ï¿œ una battua, esporre un metodo "Salva" da un singolo oggetto che 
sappia fare tutto a solo ï¿œ un approccio, che in architetturta del 
software si chiama Active Record, funziona sia chiaro, ma spesso impone 
troppo presto i suoi limiti.


troppo presto i suoi limiti.
Si, poi ho cercato Active Record e ho visto che è un pattern usato da
parecchi ORM.
ma non so perchè ma ho paura degli ORM ... :)
 
Simona
 

 metodi di SQLHELPER
 
ho capito adesso cosa intendi rileggendo tutto il thread, secondo me va 
benissimo l'approccio "LogDatabase" ma, domanda: la connessione al db? 
ï¿œ condivisa tra i vari pezzi? cioï¿œ un ipotetico ClienteDatabase e 
LogDatabase condividono la stessa connessione o ne hanno due diverse?


.m
no no
la connessione è la stessa e sta depositata nello strato DATALAYER
se ho capito bene la domanda.
è chiaro che ognuno chiama una istanza della connessione al momento
dell'operazione richiesta
 
 
 

 dell'operazione richiesta
 
ok, diciamo che nel tuo esempio potrebbe essere un problema, se stai 
salvando 2 entitï¿œ, Cliente e Log, e stanno nella stessa transazione con 
il db devi decidere se nel momento in cui il log fallisce anche il 
cliente deve fallire o viceversa (che ï¿œ peggio)


.m
non ho capito
secondo la mia logica il log di una qualunque cosa avviene se
l'operazione precedente è andata a buon fine.
secondo me questo non dovrebbe entrare nella tua esposizione.
 
ma se così non fosse tu cosa mi suggerisci per cercare di risolvere il
problema?
 
 

 problema?
 
dipende tutto molto dal contesto, ci sono scenari in cui se il log non 
riesce non deve riuscire neanche l'operazione "principale", pensa ad 
una transazione bancaria, il log della transazione è quasi più 
importante della transazione stessa.
 
Secondo me il log, inteso come tracing di quello che succede nel codice 
non va in un db, o meglio non va nel db in cui ci sono anche i dati, ma 
passa da uno dei tanti tool, log4net, nLog, etc.., che ci sono la fuori 
e magari finisce anche in un db, questo tipo di log è importante ma non 
vitale per l'applicazione, se non va è un problema ma l'applicazione 
può continuare a lavorare.
 
hai poi un tracciamento di quello che fa l'utente in termini di eventi, 
cose che sono accadute che hanno importanza dal punto di vista del 
business, questo secondo me è un dato altrettanto importate quanto, ad 
esempio, un'anagrafica cliente, quindi se mauro crea una nuova 
anagrafica e l'applicazione non riesce a tracciare che mauro ha creato 
una nuova anagrafica allora deve fallire _tutto_ il processo di 
creazione.



Grazie, sei stato molto chiaro ed illuminante.
adesso ci penso sopra.
casomai ti scoccio ancora.
 
ciao