Newsgroup: it.lavoro.informatica
Titolo: [forse OT] ma la business logic

dove la mettiamo? sul database (procedure), facciamo il secondo tier,
tutto soa oriented, web services o la mettiamo nel front-end?
chiaramente la risposta giusta sarebbe che dipende da molti fattori, uno
dei quali se dobbiamo essere indipendenti o no dal db usato, se diversi
applicativi scritti in diversi linguaggi devono accedere al db o no, e
un sacco di altra roba. ma come voi ben saprete, bisogna standardizzare
("da oggi facciamo tutto in .NET!"), e quindi bisogna trovare il
martello per qualsiasi tipo di chiodo. che dite? dove la mettiamo la
business logic?

 che dite? dove la mettiamo la business logic?
...vuoi un suggerimento su dove metterla? :-)
Massimo

 business logic?
Nel culo.

 ha scritto nel messaggio 
news:emeto0$u04$1...@nnrp.ngi.it...

Si vede che non sei laureato. 

 dove la mettiamo? sul database (procedure), facciamo il secondo tier,
 > [...]
Una domanda, tu che ne diresti se la fiat va a chiedere alla ford in che 
posizione piazzare il motore ???
;-)))
-- 
--------------------------------------------------------------------
Non system disk or disk error, replace and strike any key when ready
--------------------------------------------------------------------


Interessante osservazione. Dunque, il numero totale e la qualità di
ogni algoritmo presente nella logica di business influenza il livello
di accesso ai dati, come conseguenza io considererei questo fattore per
stabilire in modo chiaro dove mettere la BL.
Secondo me però, seguendo il rapido ritmo dell'informatica odierna, il
punto cruciale non è tanto dove la mettiamo, ma come e con quale
qualità mettiamo giù la business logic. Quindi più quest'ultima
sarà atomizzata e più sarà replicabile / separabile /
reimplementabile in qualsiasi sistema disegnato in base alle nostre
esigenze.


la BL va in un object puro e stateless. Pero' ci sono veramente tante
scuole, forse la rosellina di Sara Tommasi e' un ottimo posto dove metterla
:-)
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 chiaramente la risposta giusta sarebbe che dipende da molti fattori
.un po' di confusione in testa? ;-)
..se metti la business logic nel db, il problema non è tanto che ti leghi
al database, quanto che ci puoi fare solo operazioni su database. Business
logic non è fare solo query sul db, ma anche interfacciarti con altri
sistemi (che so, ldap, mainframe, mail server, message broker). Per quanto
non ho dubbi che i db-monstre attuali ti permettano di fare alcune di
queste cose, sono sicuro che preferirai farlo con un paio di righe di Java
o C# piuttosto che con qualche linguaggio proprietario.
..se metti la business logic nel frontend, spero di non lavorare mai con
te! ;-)
già il codice per produrre un frontend carino non è banale, se poi ci
mischiamo anche la business logic a questo punto torniamo alle care
vecchie applicazioni adolescenziali in php, con le query cablate
direttamente nelle pagine!
io la business logic la metterei nel business layer (che l'hanno inventato
apposta). Dopodiche', se l'hai costruita in modo decente, l'esposizione
della stessa (tramite pagine web, web services o che altro) la puoi
costruire in modo indipendente.
--
  Mopo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

dove la mettiamo la business logic?
Come qualcuno ti ha gia' consigliato, e' una buona scelta creare una
libreria separata (o piu' librerie a seconda dei pattern che utilizzi)
in cui racchiudere quanta piu' logica applicativa possibile. A seconda
delle specifiche del progetto una parte di essa puo' anche andare nel
db ma piu' che altro in questo caso quello che conta e' l'esperienza e
quindi la facilita' che hai nel gestire stored procedures piuttosto che
codice con dentro l'essecuelle e giu di li'.
Non mi e' chiaro se esiste, nell'architettura che hai abbozzato, il
"layer" di web services. Se la risposta e' si, rimane comunque valido
quanto detto prima in quanto un buon metodo da seguire e' quello di non
mettere logica nel web service che invece dovrebbe quanto piu'
possibile *esporre* funzionalita' la cui logica e' da un'altra parte.
Saluti

 mettiamo la business logic?
Per me dovrebbe essere un'entita' a se stante e, soprattutto, molto ben 
documentata.
-- 
ciao
mario :-)
-----------------------------
http://www.ihv.it/mario
-----------------------------

 tutto soa oriented, web services o la mettiamo nel front-end?
Dipenderą un po' dal tuo target, no?
Di sicuro se hai deciso la separazione della business logic darti 
indicazioni filosofiche di massima mi pare superfluo mentre darti 
indicazioni tecniche su come implementarla mancano dati. Puoi metterla 
nelle stored procedure? Si. Puoi fare un middleware? Si. Puoi integrarla 
nel front-end? Si. Puoi fare dei servizi web? Si.

 Dipenderà un po' dal tuo target, no?



Dove deve stare, nel mezzo.

apperò. vedo che anche tra di voi ci sono quelli con idee diverse.
rimarrà per sempre un dilemma in campo informatico :)
io la bl la metterei sul db. noi usiamo sempre oracle e i nostri
applicativi sono quasi esclusivamente gestionali che spalano dati.
quindi, secondo me, è buona norma tenere la logica che gestisce i dati,
insieme ai dati. quindi row level security per la logica sui diritti,
trigger e constraints per mantenere i dati "puliti" e procedure e
funzioni per le operazioni complesse che vanno oltre il semplice crud.
inoltre averele l bl appiccicata ai dati garantisce che non diventi
obsoleta nel giro di un paio di anni. i linguaggi di programmazione
cambiano, i front-end anche, ma i dati restano per sempre.

 cambiano, i front-end anche, ma i dati restano per sempre.
In compenso quando i commerciali ti imporranno di supportare un'altro 
DBMS inizierą il tuo blood-swimming :P


si certo. ogni soluzione ha i suoi pro e i suoi contro. da noi si usa
oracle. si usa da 10 anni e non si cambia. chiaramente č un fattore da
prendere i considerazione prima di decidere.


perņ pensandoci... se la scrivi in java e i commerciali ti impongono
un'altro linguaggio sei punto e a capo. quindi non lo vedo come un
grosso punto di svantaggio.

 grosso punto di svantaggio.
Non mi hai capito.
Essere legati ad un database dal punto di vista commerciale č un grosso 
punto a sfavore, soprattutto perchč nel 2006 (quasi 2007) gran parte 
delle soluzioni non lo sono. Presto o tardi ti chiederanno di rendere 
conto della scelta di legarti ad oracle (sempre che l'abbia fatta tu) e 
nel caso ti troveresti anche a remare controcorrente.

 nel caso ti troveresti anche a remare controcorrente.
Uh? E legarti a Java o a un qualsiasi altro linguaggio a confronto ti
mette a riparo da questa situazione? Se adesso nel 2007 proponi a
qualcuno una soluzione in access o in VB ti ridono in faccia. Fai finta
di avere implementato la bl in VB, e oggi saresti nella situazione che
hai descritto tu. Java o .NET ci sono ora, ma non sarà così per sempre.
I dati invece una volta nel DB ci rimangono.

 cambiano, i front-end anche, ma i dati restano per sempre.
I dati sono un conto, l'elaborazione che fai su di essi un altro.
Massimo

 I dati invece una volta nel DB ci rimangono.
Mai sentito parlare di sviluppo agile-incrementale, OOD/OOP, unit testing ?
Ti voglio vedere a farli in PL/SQL ;-)

 I dati invece una volta nel DB ci rimangono.
I dati stanno sul DB e su questo non ci piove :-)
La discussione è dove sta il programma.


Cioe' tu scriveresti tutta l'applicazione in Oracle ? Hai capito tutto :-)
Non oso immaginare un team di 20 persone che scrive una applicazione di 2
anni in Oracle. Prevederei un medico e uno psichiatra all'interno del team
:-)
Se poi sei in una multinazionale vaglielo a spiegare alle 10 filiali che
hanno db2 che loro non la usano.
Inoltre avresti fuori tutta la logica di integrazione e di front end, quindi
se devi scambiare dei dati con l'esterno da Oracle non lo puoi fare e quindi
devi iniziare a tirare fuori pezzi di BL e dove li metti se non hai il BL
tier ?
Insomma, sei parecchio contro corrente. Comuqnue non ti arrestano se fai
tutto in oracle , al limite il primo dirigente un po' sano di mente ti
licenzia :-)


 licenzia :-)
Na...

 accesso ai dati.
Vabbè. PL/SQL era un esempio. Faccio procedure su DB in Java, meglio? Il
punto è che secondo me deve stare appiccicata ai dati.

 Ti voglio vedere a farli in PL/SQL ;-)
Che c'entra?

 Che c'entra?
C'entra perchč ormai per ridurre i rischi di sviluppo e contenere i 
costi (e rispettare i tempi) molti usano quelle 
metodologie/tecniche/tools per sviluppare.
E farlo in PL/SQL č oggettivamente molto piů complicato (e quindi 
costoso/rischioso) che in un linguaggio all purpose (come Java o C#).

 costoso/rischioso) che in un linguaggio all purpose (come Java o C#).
Non sono d'accordo. Se mi dicevi RoR ti quotavo, ma ti assicuro che da
noi c'è gente che in PL/SQL ci mette spesso una frazione del tempo che
ci mette in Java/C#. Ma anche qui è questione di skills del team e mille
altri fattori. Ma il punto non è questo. Oracle e Postgres permettono la
creazione di procedure/funzioni anche in Java o Perl. Il punto per me
non è il linguaggio usato, ma dove mettere la BL. Se secondo te PL/SQL
non è il linguaggio adatto per implementare la BL (io non sono
d'accordo, ma non fa niente :)), ti posso rispondere che se vuoi la fai
in Java, ma comunque mela piazzi sempre sul DB.

 punto è che secondo me deve stare appiccicata ai dati.
Si ma è più complicato (quindi costoso e rischioso) sviluppare la BL con 
stored procedure piuttosto che seguire il diffusissimo (e ben 
conosciuto) design pattern MVC.
Chi ha fatto grossi progetti in programmazione strutturata alla 
Cobol/Pascal/Basic sa cosa voglio dire :-)

 conosciuto) design pattern MVC.
Adesso non ti seguo piů. Model View Controller č un pattern che viene
usato in Struts e in Ror o comunque per il FE. Viene usato per separare
la presentazione dei dati dalla gestione dei dati. Che centra la BL?

 Dici?
Da come tu stesso hai iniziato ad ammettere va bene per programmini piccoli
, che non necessitano di integrarsi ad altri sistemi, per aziende piccoline
che hanno 1 solo database.
Che non hanno elaborazioni grafiche, non hanno scambi di dati con altri
Sistemi, non hanno non hanno, non hanno ...
Aggiungi che se tu sei una SF house non puoi limitarti a vendere solo pe run
DB perche' beccheresti del 100% dei progetti i 10% che accettano una
soluzione cosi' estrema come quella da te proposta e di questo 10% ti
prenderai il 3% di mercato che e' il DB in cui ti specializzi, e poi non
puoi rivendere agli altri. Un suicidio.
Poi ognuno fa quello che vuole.
Se vuoi fare una via di mezzo fai tutto con Oracle Application Server che e'
un buon compromesso fra le 2 cose.
Nicola
Certo per una applicazione CRUD molto elementare la soluzione DB e' una
soluzione come le altre.



Purtroppo parli senza conoscere. Il java che puoi usare in Oracle e' il 5%
del java che usiamo per produrre applicativi.
Mai sentito parlare di JEE ? Quello non lo puoi usare se non in Oracle
Application Server.
Siccome il 99% dei progetti oggi sono JEE non puoi parlare di scrivere Java
in Postgres


 Poi ognuno fa quello che vuole.
Chiaro :)

 in Java, ma comunque mela piazzi sempre sul DB.
Se piazzi la BL sul DB di fatto hai un forte accoppiamento fra i due.
Per piccoli progetti o piccole aziende può anche andare bene (anche se 
va contro i principi di un buon design).
Ma per una grande azienda/multinazionale può essere un bel problema.
Come dice Nicola se devi integrare sistemi diversi che fai ?
Scrivi altre stored procedure per chiamare quei sistemi (con tutte le 
complicazioni del caso) quando il resto del mondo usa un ESB come questo 
http://www.jboss.org/products/esb
 ?
Se devi dare accesso remoto (filiali dell'azienda) alla BL o scrivere 
sistemi di workflow management/BPM che fai, rendi le stored procedure 
accessibili via xml ?
Si può fare ma dipende sempre dal contesto.
Ho visto in passato ambienti enterprise dove la BL era sparsa in 40000 
programmi diversi scritti in Pro Cobol, Pro C, PL SQL ed era un delirio 
assurdo capirci qualcosa (De Agostini ti dice niente ?)
Avessero fatto la BL tutta centralizzata in pochi package PL SQL ancora 
ancora ... ma invece :-(
E non sono gli unici a fare quel casino quando schiaffano la BL sul DB.

 in Postgres
Mi dici cosa che tipo di BL hai che ti rende necessario avere tutte le
classi di J2EE che non puoi fare su Oracle in PL/SQL o Java? Se non hai
un'applicativo che deve gestire un migliaio di filiali sparse per il
mondo sinceramente mi sembri esagerato. Comunque tutto può essere.

 Chiaro :)
Nicola


 mondo sinceramente mi sembri esagerato. Comunque tutto può essere.
Banche
Assicurazioni
Energia
Telco
Siti internet
Pubbliche amministrazioni
Automobili
Gomme
.....
sono i primi settori venuti in mente a caso che hanno 50+ filiali


 nell'informatica. Non pensare che fatto quello fai volare gli shuttle
Non lo penso. Ma chiamarli piccoli č un eufemismo.

 linguaggio scelto?
Non mi risulta che nessuno dei linguaggi citati abbia soppiantato o reso 
obsoleto un qualsiasi altro. Java, Ruby e Python esistono da quasi tre 
lustri, .Net ormai da 7 anni. La tua idea di ciclo di vita dei linguaggi 
è quantomeno opinabile.

 la presentazione dei dati dalla gestione dei dati. Che centra la BL?
http://java.sun.com/blueprints/patterns/MVC.html
"Several problems can arise when applications contain a mixture of data 
access code, business logic code, and presentation code. Such 
applications are difficult to maintain, because interdependencies 
between all of the components cause strong ripple effects whenever a 
change is made anywhere. High coupling makes classes difficult or 
impossible to reuse because they depend on so many other classes."
In particolare
"Data access code suffers from the same problem, being cut and pasted 
among business logic methods."
Che è il motivo per cui disaccoppi Data Access Layer da Business Logic.
La manutenzione evolutiva è più semplice.
Se poi riesci a fare decoupling bene tramite package PL/SQL buon per te.
Ma imho si fa meglio tenendo la BL fuori dal DBMS.

 sono i primi settori venuti in mente a caso che hanno 50+ filiali
Con 50+ non lo capisco. Secondo me usi una motosega per farti un panino.
Comunque non conosco i tuoi progetti quindi mene tengo fuori.

 Bč, direi che č ininfluente.
Mica tanto. la tentazione di scrivere codice nel linguaggio del FE sara'
quotidiana e alla fine come ha detto Jarod avrete pezzi in C pezzi in
Oracle, pezzi in Java, pezzi di codice magari nella JSP o PHP o ASP
insomma la classi porcheria, chimaata anche spaghetti integration.
Sapere che la mi BL sta tutta in un Application Server. Tutta nello stesso
linguaggio, tutta predisoposta ad integrarsi col resto del mondo, che il mio
AS oggi ha dentro anche il WS, che gestisce benissimo i database.
Che si puo' fare il cluster SW , oltre a quello HW. Che ho la transazione di
logica e dati gestita dall'application server
insomma e' quanto di piu' pulito, ordinato, scalabile, portabile,
manutenibile, vendibile, riusabile possa avere in mano.
Se cio' non ti interessa, fai benissimo a stare in Oracle, che fra l'altro
e' ottimizziato per le prestazioni.


 Cosa ti manca per la BL? Se mi dici SWING o AWT vengo a picchiarti :)
Ti invito solo a dare un'occhiata a questo progetto java di integrazione:
https://appfuse.dev.java.net/
Da notare come viene implementato separatamente web, manager, e dao. I 
vantaggi? Il manager (o business logic) lavora sui dati senza 
preoccuparsi minimamente da dove provengono, come reperirli e come 
salvarli.
Ma se vogliamo, anche l'architettura di Ado.Net è strutturata in modo 
analogo con i dataset al posto dei bean e gli adapter invece dei dao.
Ti invito anche a dare un occhiata al pattern dao e rivedere le tue 
convinzioni (se ce l'hai) sul fatto che avere a disposizione della 
business logic l'accesso ai dati via SQL sia un bene. Per me e per molti 
altri è deleterio.
Infine, considera che esistono strumenti per la persistenza dei dati che 
sono studiati apposta per astrarre il programma dal database.

 sono studiati apposta per astrarre il programma dal database.
Cosa ti fa pensare che io non conosci Hibernate o iBATIS? Queste due
soluzioni hanno due grossi difetti nei miei occhi:
- cache dei dati al di fuori del db - integrità referenziale che sene và
- partono dal presupposto di essere gli unici a manipolare i dati,
invalidando tutti gli altri paradigmi di programmazione (cene sono anche
altri!)

 e' ottimizziato per le prestazioni.
Uhm, questa frase mi fa pensare a un talebano dell'n-tier: la mia
soluzione è la più figa, tutto il resto è merda :)

 altri!)
Una cache dei dati che non tiene conto della concorrenza la potrebbe 
scrivere anche un bambino, diciamo che questi framework sono un 
capellino più avanti per non tenere conto di una problematica così 
elementare.
Ma a parte questo, cosa c'entra l'integrità referenziale? Quella sì che 
va sul database, il fatto che (eventualmente, non è obbligatorio) viene 
mappata via software è un plus.