Newsgroup: it.comp.java
Titolo: Java e accesso ai dati - Considerazioni

Salve a tutti,
volevo proporre al ng una considerazione relativa all'accesso ai dati da 
parte di programmi Java o Java Enterprise,
ma che, in realt�, potrebbe IMHO estendersi ad altri linguaggi, come ad 
esempio C#. Rimaneniamo, per�,
in tema.
Mi sembra lecito poter affermare che in questi anni sono stati creati 
diversi strumenti per risolvere il problema
di rendere persistenti gli oggetti su database relazionali. Penso ad EJB, ai 
JDO, ad Hibernate, a JPA. Quest'ultimo strumento,
in particolare, � sintesi degli sforzi (e dei fallimenti, anche diciamolo 
pure) di altre esperienze. Tramite JPA, una POJO
opportunamente annotata pu� essere resa persistente, grazie ad un entity 
manager. Anni luce pi� comoda e semplice
degli "antichi" EJB Entity, direi, e su questo punto credo che tutti siano 
pi� o meno d'accordo.
Studiando per� JPA, mi sorge un dubbio che non credo sia banale. Vi sono 
diverse situazioni in cui JPA non pu� bastare,
ad esempio quando il reperimento dei dati dal DBMS ha una logica molto pi� 
complessa da quella che si pu� implementare
in un metodo findBy piuttosto che tramite una query JP-QL.  Situazioni in 
cui, senza farla troppo lunga, sarebbe assolutamente
logico ricorrere a stored procedures, cosa che � pur sempre fattibile 
tramite JDBC.
Per quanto riguarda le stored procedures, esse sono decisamente efficaci ed 
efficienti, ma hanno il problema di non essere portabili
tra dbms diversi. Certo, esistono le Java Stored Procedures, ma IMHO peccano 
decisamente di efficienza (almeno nei casi in cui
ho provato ad usarle). Pertanto, mi sono chiesto se tra JPA e stored 
procedures non fosse possibile una maggiore imtegrazione,
ma ho trovato ben poco.
Qualcuno vuole illuminarmi, in proposito ?
Scorpio

ma ho trovato ben poco.
Ilmotivo per cui e' molto ma molto difficile passarle sotto JPA e' lo
stesso identico delle view residenti. E cioe' l'id.
Tutta la jpa si basa sull'id. Ogni elemento ( entity o pojo che sia ) ha
il suo id e in base a quello viene rintracciato l'elemento in memoria
oppure caricato se manca e in base agli id si decide quali scaricare
eccetera.
Le view e le stored NON POSSONO AVERE UN ID sulle tuple in uscita e
pertanto la JPA va totalmente in bambola per come e' stata pensata.
Ottima discussione, speriamo altri portino le loro considerazioni, che
interessa pure a me :-)
Ciao ciao
Nicola
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 arrivare al punto che anche l'80% del codice lo mettono la' dentro
Questo � uno spunto interessante. Di *regola*, le applicazioni devono 
distinguere
tra logiche applicative e logiche pure di accesso ai dati, ma pensiamo a 
scenari
in cui l'applicazione � essenzialmente datacentrica, ad esempio un ERP. Dove
finisce la business logic e inizia la logica di accesso ai dati, o viceversa 
?
Il confine, IMHO, � estremamente labile.
Facciamo anche un piccolo esempio.  Supponi di gestire un order entry. Se si 
tratta
del classico carrello della spesa di una societ� XYZ, l'accesso ai dati 
occupa certo una parte
del problema, ma una volta che hai scritto il tuo ordine su dbms, � lecito 
aspettare
che sar� il back-end office a validarlo.
Ora, pensiamo invece ad uno scenario complesso: l'operatore che sta 
validando il tuo
ordine. L'ERP, in questo caso - se XYZ produce i prodotti che vende on 
line - potrebbe
ad esempio interrogare la disponibilit� in deposito dell'articolo / articoli 
acquistati, registrare
la movimentazione di deposito, e, eventualmente, se il livello di scorta del 
prodotto acquistato
scende una certa soglia, emettere un ordine di produzione (o di acquisto, se 
la merce � prodotta
da terzi).... Lo stesso prezzo potrebbe essere fissato a regole 
essenzialmente basate sullo storico
del cliente (es: rapidit� nel pagamento, fedelt� negli acquisit) o 
contestuali (es: quantitativi di merce
acquistati per volta).
D'accordo, l'ho messa gi� dura :-) ma situazioni di questo tipo sono 
tutt'altro che rare. In ottica J2EE certamente
avremmo un bell'ejb che esegue in cascata i vari step sopra descritti.... 
oppure una chiamata ad una stored
registraOrdine() e via andare. Quale scenario � migliore ? Concettualmente, 
forse il primo: le redini della
situazione (ossia, il flusso logico del processo "convalida ordine" ) sono 
in mano ad un componente della
business logic. Ma dal punto di vista prestazionale, l'uso di una stored che 
accede ai dati �, a priori, mooolto
pi� performante. E pi� prona a modifiche "on the fly" (DBA permettendo) : ad 
esempio, se il prodotto acquistato
fosse un "fine serie", il discorso del riordino non andrebbe fatto.... e si 
tratta di un controllo che, se "cablato"
nell' EJB, sarebbe rilasciato solo con un deploy "ad hoc", probabilmente.
Che ne pensi ?
 Scorpio. 

 Che ne pensi ?
Penso che l'unico vero pro a favore delle stored siano le prestazioni. I
contro sono innumerevoli, io ho proposto solo i primissimi che mi sono
venuti in mente.
Nella stragrande maggioranza di applicazioni aziendali che facciamo noi le
prestazioni non sono un problema. L'intero JEE si rivolge a quella enorme
fetta mercato che non ha alcun problema se una richiesta impiega 1 3 o 5
secondi per essere evasa e spessissimo il collo di bottiglia sta nella rete
o in altri punti non database.
Prendiamo l'ERP che hai citato te. Un erp e' B2B, cioe' lo usano solo
all'interno della intranet le persone autorizzate e qualificate.
L'erp di una ditta di facliatrici con 20 dipendenti lo usano in 2 o 3
persone un paio di volte al giorno. Problemi di prestazioni non ce ne sono
L'erp della FIAT e' un progetto ventennale con un budget che poitrebbe
essere dai 10 ai 100 milioni ( stando basso ) in 20 anni enon vi e' alcuna
ragione di volere risparmiarci sopra su briciole del genere per loro.
L'hardware quindi e' mostruoso e anche ammettendo che lo usino 5000 o 20000
dipendenti non ci saranno problemi di prestazioni. 1-5 secondi per una
ricerca sono un tempo iper accettabile
Quindi il j2ee senza scomodare le stored ce la fa benissimo sia in
microaziende che in megaaziende e offre i vantaggi che noi conosciamo su
altre tematiche non prestazionali
I rarissimi settori che richiedono prestazioni, i videogames, i real time
system  eccetera certamente non usano il JEE e useranno sterd o tecnologie
similari, ma pochi di noi javisti si occupano di queste tematiche
Nicola
Insomma risulta forse un "tirarsi addosso i guai di 2 mondi tendenzialmente
esclusivi" mixare JEE e stored.
Questa e' in sintesi la motivazione di fondo per cui secondo me si tende a
scegliere all'inizio una o l'altra strada.
-- 
Nicola

 prestazioni non sono un problema.
Domanda sciocca: non sono un problema, nel senso che non ne avete, o non 
importa
se i tempi di risposta sono mediocri ?
Scorpio