Newsgroup: it.lavoro.informatica
Titolo: dove metto la business logic?

cioè l'utente ha appena cliccato "fammi la somma delle fatture del 2009"
- tiro su tutte le fatture dell'anno, luppo sulle righe e le sommo[1]?
- faccio un select sum(lordo) from fatture?
[1]
http://j.mp/d9iBU1
posso generalizzare la regola?
dove metto
- logica sulla consistenza dei dati
- logica che elabora dati
- logica sulla sicurezza dei dati (ad esempio un utente con ruolo 
"segretaria" può vedere e inserire gli appuntamenti, ma un utente con 
ruolo "impiegato" li può solo vedere)
supponendo che il database che uso è quello e rimane quello per almeno i 
prossimi 10 anni, e anche il linguaggio di programmazione che uso è 
stabile, che dite?

 ruolo "impiegato" li può solo vedere)
Nel modulo che gestice la sicurezza a livello di applicativo, le
singole funzioni non devono incorporare sicurezza

 funzioni non devono incorporare sicurezza
hmm e se la mettessi dentro alla stored che richiamo dal dal? tipo che 
invece di fare
select campi from tabella
ci metto direttamente
select campi from tabella where ruolo = quellochehai
?

 stabile, che dite?
dai su, riveliamo peccati e peccatori: il database è oracle, il 
linguaggio è pl/sql e la sicurezza sui dati di cui parli è quella che 
fornisce oracle stesso :-)
della sicurezza sul dato assolutamente non mi interessa quando scrivo un 
programma. secondo me non ha senso. ha più senso gestire la sicurezza a 
livello di operazione di business logic, su java ti potrei suggerire 
articoli di questo tipo sulla sicurezza e aop:
http://www.symantec.com/connect/articles/aspect-oriented-programming-and-security

 
http://www.symantec.com/connect/articles/aspect-oriented-programming-
and-security
tnx. ancora non so se sarà java o php o python o c#. per l'architettura 
vorrei tenermi il più flessible possibile. ma comunque con la certezza 
che una volta scelto qualcosa quello rimane.

 select campi from tabella where ruolo = quellochehai
Non mi piace. La sicurezza deve essere demandata ad un gestore
apposito che decide se il campo è visibile o meno sulla maschera e che
risponde ad una qualche forma di configurazione. Se lo mischi nel
codice e cambia qualcosa nel modello di sicurezza dopo qualche tempo
sei fatto.

 qualcosa nel modello di sicurezza dopo qualche tempo sei fatto.
eh, concordo.

 gestire i ruoli
Non capisco completamente cosa vuoi dire.... se la segretaria può andare 
di read/write e l'impiegato solo di read, potresti associare ad ogni 
ruolo un utente per il collegamento al database e poi dare un livello 
aggiuntivo di sicurezza giocando opportunamente con le grant... in 
questo modo accentreresti parte del filtro nel database...
Ad ogni ruolo potresti poi associare una vista specifica così da poter 
mascherare campi in lettura...
... ci sono tanti possibili modi... occorrerebbe conoscere meglio il 
dettaglio del tuo caso per poter dare indicazioni più precise...

 sicurezza del dato e che si deve occupare di "filtrare" questi dati.
Just a moment. Se mi parli di sicurezza del dato al livello di chi
deve vedere cosa, ad esempio se certi utenti possono vedere solo le
fatture emesse da loro/la loro divisione, non ho un approccio
"standard", dipende moltissimo da come sono strutturati i dati. Si
cerca sempre di portarli su un albero o comunque un grafo e poi fare
funzioni standard di filtraggio, il che vuol dire lavorare a codice o
dentro le select ma con sql dinamico o join sempre uguale.
Ma a volte è molto meglio rimanere sul pratico e fare join secche
perchè alla complicazione non c'è mai fine se si cerca di
generalizzare eccezioni su eccezioni : bisogna arrendersi e farli una
tantum.
Se invece mi parli di accesso a tabella ci sono le grant, se ancora mi
parli di sicurezza del genere le segretarie non possono fare la sum ci
sono le autorizzazioni della stored.
Se però vuoi replicare la sicurezza del font-end nella bussines perchè
teoricamente bisognerebbe farlo... o usi servizi di disaccoppiamento
tipo web service ed allora ha un senso, oppure non ti seguo :  è una
complicazione che non da vantaggi e di cui nessuno si accorgerà mai.
Ti fai mille problemi e poi i dati tanto accuratamente protetti gli
utenti se li scambiano con excel o con file piatti con le email...

 aggiuntivo di sicurezza giocando opportunamente con le grant... 
sono modelli ingestibili, a meno che non sposi in toto le tecnologie di 
sviluppo che ti da un certo produttore del database ma allora diventa 
devastante. imaginati te di dover gestire gli accessi a livello di dati 
in modo che l'operatore di cassa possa fare gli scontrini fiscali ma non 
possa, ad esempio, annullarli. spesso e volentieri la sicurezza non è 
riconducibile all'oggetto database ma all'operazione che lo coinvolge, 
per questo generalmente la si sposta più in alto. ci sono ovviamente dei 
casi particolari che hanno questa necessità (penso alla tabella che 
contiene i pan delle carte di credito) ma in generale è imho una volontà 
di essere più realisti del re. e si sa che in ambito sicurezza più il 
modello è articolato e più è bucabile.

 applicativo, limitando la modifica alla vista.
In molti db la s.p. è consigliata perchè più performante rispetto alle
semplici select costruite dinamicamente ogni volta.
Ma non capisco che utilità avrebbe il disaccoppiare dalla vista, la
quale è già un disaccoppiamento dalla struttura delle tabelle.
E se cambi la vista, ad esempio aggiungi o togli dei campi, come fai a
non cambiare la s.p. e di riflesso il codice applicativo? Boh. Sempre
volendo considerare la s.p. come esterna al codice specifico
dell'applicativo, cosa che spesso non è vera, nel senso che la s.p. di
fatto vive solo per una singola applicazione.

 semplici select costruite dinamicamente ogni volta.
In effetti c'è un altro possibile motivo: le istruzioni SQL costruite
dinamicamente possono "lasciare traccia" entro gli eseguibili,
es. .class Java, perchè sono delle semplici stringhe. Se invece si
richiama una s.p. ogni dettaglio del db (nomi tabelle, campi, ecc.) è
del tutto esterno all'eseguibile, quindi non accessibile anche nel
caso eventuale che l'eseguibile finisca in mani sbagliate.

 applicativo, limitando la modifica alla vista.
LOL, l'ho visto fatto in passato per fare DW su un DB per OTP, con
esiti su DB in produzione tragici dal punto di vista prestazionale e
reputazionale.
BTW in laboratorio, se il database è piccolo e le query semplici, in
generale funziona, nel mondo reale paghi quello che mangi.
--
ale
http://ale.riolo.co.uk


Scusa, puoi dettagliare meglio?

 Scusa, puoi dettagliare meglio?
L'idea (non mia) era "facciamo reportistica sul database usato per le
transazioni, invece di creare un nuovo database per ospitare i dati in
tabelle denormalizzate e senza doverci preoccupare di ETL e
quant'altro". E giù di viste (che si sperava aiutassero anche a
ridurre l'impedenza tra il DBMS ed il framework per la reportistica).
In laboratorio funziona (l'ho fatto, e lo faccio, n-mila volte per
analizzare un set di dati), quando poi dai il tutto in mano ad un
grande cliente, che ci pompa dati come un ossesso, prima che certe
query ritornino ti puoi fare un giro del mondo in mongolfiera.
Al solito, in certi ambienti e sotto certo condizioni certe idee vanno
benissimo, in altri casi no, ed in fondo there ain't no such thing as
a free lunch.
--
ale
http://ale.riolo.co.uk


Be', si, basta però che ci sia una sicurezza di aver misurato e provato 
diciamo tutto prima di valutare una strada piuttosto che un'altra.

 diciamo tutto prima di valutare una strada piuttosto che un'altra.
Nel caso in questione io sono stato chiamato a cavalli scappati dalla
stalla, il tutto l'aveva progettato e realizzato un consulente
esterno, un professionisa esperto con in saccoccia n progetti simili
(no intermediari, tranne l'head hunter).
--
ale
http://ale.riolo.co.uk

 reputazionale.
Scienziati!
E chi sa perchè tutto il resto del mondo fa un DB a parte..

 E chi sa perchè tutto il resto del mondo fa un DB a parte..
LOL
Esattamente la prima cosa che ho detto quando mi hanno presentato il
problema. :)
--
ale
http://ale.riolo.co.uk

 teoricamente bisognerebbe farlo...
bè, se implemento la sicurezza con le rules in pg, quando faccio
select * from tabella
già mi trovo solo le righe che mi servono, quindi non devo replicare 
niente.
comunque grazie per la discussione, mi sono chiarito le idee.

 comunque grazie per la discussione, mi sono chiarito le idee.
Informatica applicata, magari discuterne più spesso ;-)

 quant'altro".
Un genio, senza ombra di dubbio :-) 


La logica va sempre messa a livello piu` basso
Vale

La logica va sempre messa a livello piu` basso
Come la tua laurea?
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 La logica va sempre messa a livello piu` basso
squilla il telefono, rispondi che è meglio.

 ... ed in fondo there ain't no such thing as a free lunch.
TANSTAAFL :-)