Newsgroup: it.comp.java
Titolo: [Architetture (o chiacchiere da bar)] Uso delle stored procedures.

Salve a tutti,
solita domanda un po' oziosa un po' seria. Tempo fa stavo revisionando il 
codice di un collega e mi sono accorto che, per eseguire l'accesso ai dati, 
il collega aveva fatto ricorso in modo esclusivo a delle stored procedures. 
Chiestogli il perchè di questa scelta, ha risposto, un po' con l'aria di chi 
la sa lunga che *deve* far capire le cosa a chi non la sa altrettanto lunga, 
che l'adozione delle stored procedure per accedere ai dati è di gran lunga 
la più efficiente.
Io l'ho lasciato ovviamente terminare il lavoro, però dentro la mia testa ha 
cominciato a girare una rotellina, ossia un dubbio, su quando sia necessario 
ricorrere a delle stored procedure e quando no.
A ben pensarci l'uso delle stored procedures ha dei vantaggi che va al di là 
della pura efficienza: ad esempio mi viene in mente la possibilità di 
ricompilare le stored procedures "al volo" in caso di modifica dei criteri 
per estrarre un certo cursore dal database. Altro esempio che mi viene in 
mente è un'operazione di "write" intesa come "insert/update": se fallisce 
una insert (perchè il dato esiste già), esegui una update usando una certa 
chiave.
Il problema di questo approccio è, chiaramente, la dipendenza dal "dialetto" 
specifico del dbms per scrivere le stored procedures. Ma, a parte questo 
inconveniente - che può essere nullo se per forza o per amore ci si lega ad 
un certo vendor - quali altri svantaggi presentano le s.p ?
La butto lì - un po' provocatoriamente : se (grande SE)  non ci fossero i 
vari dialetti ma un linguaggio standard per ogni vendor, avrebbe ancora 
senso la "rincorsa continua" ai motori di persistenza ?
Scorpio.

 senso la "rincorsa continua" ai motori di persistenza ?
Cosa intendi con "motori di persistenza", gli ORM?
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/05/schermare-le-remoteexception.html

ricorrere a delle stored procedure e quando no.
Per essere efficiente, è efficiente (anche perché di solito le s.p.
sono precompilate dal DBMS), ma il problema è più che altro di
approcci. Nell'azienda in cui lavoro come consulente, c'è una
suddivisione del lavoro tra analisti, sviluppatori, DBA, ecc...
La politica del cliente è che qualsiasi gestione dei dati passa da una
procedura o funzione Oracle. Questo approccio ha diversi "drawbacks",
come l'essere un cannone per sparare alle mosche in molti casi,
l'obbligo a scrivere codice di fatto procedurale, difficilmente
debuggabile, difficilmente integrabile, ecc.. ecc..
I vantaggio, sostanzialmente, sono l'isolamento del codice di accesso
e gestione dati in un punto solo, la possibilità di correggere errori
senza dover ridistribuire l'applicazione, l'efficienza di cui sopra,
la possibilità di assegnare il compito di scrittura di una determinata
procedura a chi conosce il DB molto meglio dello sviluppatore. Io
scrivo tranquillamente le mie procedure/funzioni in PL/SQL, però
ammetto di aver dovuto chiedere spesso chiarimenti ai DBA, per
particolari statement, e questo è sicuramente tempo perso.

 
In diverse mie applicazioni che devono operare su un DB, abbiamo deciso 
di fare uso delle stored procedures, per poter centralizzare in un unico 
  punto le operazioni di lettura e scrittura, e mettiamo a disposizione 
quelle a tutte le applicazioni che devono leggere e scrivere gli stessi 
dati.
Nel mio caso l'efficienza e' strettamente legata alla manutenzione del 
codice e all'eliminazione di inutili ridondanze.
Se invece parliamo di efficienza in termini di performance 
dell'applicazione, si sgrava l'applicazione esterna dal possedere del 
codice SQL embedded, che probabilmente potrebbe venire scritto male, e 
inserendolo in una stored procedure, questo puo' essere testato 
indipendentemente dall'applicazione.
Se pero' non ci sono problematiche di riutilizzo e il codice SQL e' 
efficiente di suo, io non credo che vi sia piu' di tanta differenza di 
performance ad averlo embedded piuttosto che in una stored procedure.
Tanto la connessione al server SQL deve avvenire comunque.
Il server deve eseguire la query comunque.
Averci i comandi SQL gia' sul server piuttosto che passarli con un 
metodo, cambia ben poco.
A meno che l'operazione da fare sia quella di travasare un recordset in 
un altro, che allora nel caso della stored procedure, resta tutto sul 
server, mentre usando un recordset sul client bisogna recuperare i dati 
per poi rimandarli indietro, e allora si' che si appesantisce tutto.
In conclusione direi proprio che ci sono casi in cui la stored procedure 
e' piu' efficiente, e altri in cui e' indifferente.
In nessun caso e' piu' efficiente una executeQuery embedded, quindi il 
tuo collega qualche ragione ce l'ha.

il la faccio abbastanza semplice stored procedure solo per necessità di
prestazioni o casi molto particolari, per il resto c'è java, codice molto
più facile da mantenere, da debuggare, da portare .. 
poi dipende come sempre dal cliente e progetto, alle volte non è una
scelta :D
-- 
Davide Consonni

 senso la "rincorsa continua" ai motori di persistenza ?
Dici bene: "grande SE".
Già ora non è raro, anzi, trovare discrepanze nel linguaggio SQL, non 
oso pensare al risultato se si cercasse di standardizzare anche le sp (e 
proposte ne son state fatte parecchie) ;)
Ciao,
Paolo

 migrare tutto...
E che ci vuole! Oracle --> Postgres :-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 metodo, cambia ben poco.
Nel caso dell'invocazione della SP, a parte l'ottimizzazione spicciola di
non dover passare troppi dati dal client al server, c'č di buono che il
codice della SP č compilato, sul server. Lo stesso di ottiene con la
prepare degli statement, ma almeno la prima volta c'č un po' di lavoro in
piů. Quindi comunque il sistema delle SP č piů efficiente.


 Cosa intendi con "motori di persistenza", gli ORM?
Esattamente. EJB 2.0 Entity, JPA, Hibernate e via discorrendo: una "corsa 
agli armamenti" per risolvere il problema di mappare un bean su una tabella 
e viceversa....
Scorpio. 

 proposte ne son state fatte parecchie) ;)
Vero, è un "grande se" il mio....
Ciao,
Scorpio.

 E che ci vuole! Oracle --> Postgres :-)
Giusto per non fare nomi,vero ? :-)
Scorpio 

 e viceversa....
L'esigenza a cui vanno incontro gli ORM e cambiare il modello di 
astrazione dei dati da tabelle a oggetti.
Anche se esistesse un SQL standard usato da tutti i vendor credo che 
l'esigenza rimarrebbe.


E che ci vuole! Oracle --> Postgres :-)
Guarda, finquando si fosse limitato a "il più diffuso rdbms", il
raggio sarebbe stato ancora ampio, ma poi ha aggiunto 80mila euro
l'anno di licenze e si è fregato :-P

 un certo vendor - quali altri svantaggi presentano le s.p ?
per quanto riguarda l'utilizzo sopra citato, che sostanzialmente un 
abuso dello strumento, lo svantaggio è che come minimo non c'è vantaggio.
in generale però l'uso delle stored procedure consiste nello spostare 
una parte della logica applicativa da java al database e questo è uno 
svantaggio. e più sposti la logica sul db, più aumenta la necessità di 
gestire anche le transazioni a quel livello; se cominci a mettere 
commit/rollback nelle stored procedure ti puoi scordare tutti i bei 
discorsi sulle transazioni degli ejb, di spring, di gestione 
dichiarativa delle transazioni e compagnia danzante.
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

svantaggio. 
Non essere così categorico: dipende dai contesti. Anch'io ho creduto
per un certo tempo che fosse sempre bene mantenere la logica a un
livello meglio organizzabile, manutenibile e su cui fosse abbastanza
facile intervenire. Mi sono poi reso conto che quando c'è eterogeneità
di sistemi, spostare la logica di business su database (se non altro
come politica aziendale) non è una cattiva idea (fermi restando gli
svantaggi di cui parlavo in un altro post... s'intende). In linea di
massima sono d'accordo con te, però dipende molto dalle situazioni.

 E che ci vuole! Oracle --> Postgres :-)
Beh dai, era facile! ;)
Un po' meno facile migrare circa 18Gb di db, con parecchie tabelle piene 
di "schifezzuole"... vedrem.
Ciao,
Paolo

 l'esigenza rimarrebbe.
Esigenza per chi ha una visione oggetto-centrica del mondo :-)
Non è un'esigenza sentita comunemente in altri linguaggi/sistemi.


 Non è un'esigenza sentita comunemente in altri linguaggi/sistemi.
D'accordo. Quello che volevo dire è che chi ha quella esigenza c'e' l'ha 
anche dopo che arriva l'SQL ultra portabile.
Chi non ce l'ha non ce l'ha.
-- 
Andrea Francia
http://www.andreafrancia.it/


siete davvero sicuri di voler passare da oracle a postgres? :)
La gestione delle transazioni in postgres è molto diversa da quella in
oracle. E' molto più limitata e molte SP potrebbero essere inservibili
e da rifattorizzare pesantemente.
Si attendono smentite.

 Si attendono smentite.
Non da me :)
L'unica fortuna è che nel db oracle ci sono pochissime S.P..
Le cose che più mi preoccupano sono altre, ma non sto qui ad annoiarti...
Ciao,
Paolo

 massima sono d'accordo con te, però dipende molto dalle situazioni.
Quando, secondo te, e' utile spostare parte della logica di business 
nella base dati?

nella base dati?
A volte è una pura e semplice scelta politica, comunque è una cosa
logica da fare quando ci sono sistemi eterogenei che devono sfruttare
le stesse regole di business, oppure c'è una suddivisione netta tra
chi scrive il codice e chi gestisce e ottimizza il DB. A volte questa
divisione è utile perché fa risparmiare tempo. Per esempio, a me è
capitato (per strane logiche del cliente, ma è un altro discorso) di
dover scrivere un processo che travasava, a intervalli definiti e
tramite un dblink Oracle, dei dati da una tabella all'altra, dovendo
stare attento ad aggiungere i nuovi record ed aggiornare quelli già
presenti. Ovviamente la prima cosa a cui ho pensato è di fare
controlli mediante i soliti comandi SQL. Oracle, invece, mette a
disposizione la potentissima istruzione MATCH. L'ho trovata perché ho
cercato, però magari tanta gente la briga di cercare queste
informazioni manco se la piglia.

 massima sono d'accordo con te, però dipende molto dalle situazioni.
io non sono d'accordo. a meno che non sia forzata da vincoli 
architetturali (in particolare di obsolescenza) non la trovo una scelta 
felice, anzi direi che tende a peggiorare la situazione. non vorrei 
passare per quello che vende tecnologie alla moda, ma onestamente oggi 
come oggi in una infrastruttura eterogenea non pensare ad una 
architettura service oriented mi sembra quasi voler fare un danno. anche 
perchè fra scrivere un web service e una store procedure è più semplice 
il primo (anche in java, il che è tutto dire :))


architettura service oriented mi sembra quasi voler fare un danno. 
Su questo sono d'accordo, ma non vorre si facesse confusione: web
services e stored procedure non sono necessariamente alternative.

 
http://www.andreafrancia.it/
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


In linea generale avere la logica nel db e' un massacro
La logica e' molto meglio che stia nell'applicazione
per tutti i punti di vista ec cetto che per le prestazioni, che molto
raramente sono vincolanti.
ciao Nicola


 La persiostenza dati serve per la portabilita' al 10%
Immagino volessi dire al 100%.
Ma in altri linguaggi/sistemi, la portabilità totale si ottiene
ugualmente, anche senza far uso di framework di persistenza e con la
stessa facilità.
Voglio solo sottolineare che usare un framework di persistenza non è
sempre indispensabile.


 sempre indispensabile.
mahhhhhhh ne dubito, forse per il tetris non serve ...... :-)


 mahhhhhhh ne dubito, forse per il tetris non serve ...... :-)
Mi prendi in giro? non è così. Probabilmente hai una visione troppo
java-centric dello sviluppo.


 In linea generale avere la logica nel db e' un massacro
E' molto più che falso.


 java-centric dello sviluppo.
E' molto probabile.
Una volta ero piu' multipiattaforma. Oggi all'11esimo anno di Java senza
dubbio un po' di visione globale la ho persa ;-)


 
In linea generale qualsiasi affermazione è vera e falsa allo stesso tempo.
E quando si entra nello specifico che si può discutere di qualcosa di 
concreto.


 In linea generale qualsiasi affermazione è vera e falsa allo stesso tempo.
Ma chi sei? il filosofo del gruppo?
Che significa che "qualsiasi affermazione è vera e falsa allo stesso
tempo"? 
Dal mio punto di vista, che la logica di business spostata su sp sia un
"massacro" è falso e basta. E per dirlo, ho dei riferimenti concreti sotto
gli occhi, una situazione con cui ho a che fare giornalmente.


 gli occhi, una situazione con cui ho a che fare giornalmente.
n.n non ha detto che è vero sempre. Ha detto che è vero solo in linea 
generale. Che equivale a non dire niente.
Finché si parla "in linea generale" l'affermazione di n.n. non puo' 
essere ne verificabile ne confutabile.
Anche se tu porti esempi concreti uno potrebbe sempre dire che 
potrebbero essere casi isolati e l'affermazione non verrebbe confutata.
Di contro l'affermazione non è neanche verificabile. Cosa vuol dire in 
linea generale? La maggior parte delle volte? Chi ha un'esperienza 
obiettiva e non soggettiva di quello che succede la maggior parte delle 
volte.


 generale. Che equivale a non dire niente.
scusami eh, ma se hai voglia di buttarla nel nonsense dillo prima.
in linea generale significa in linea generale, se non lo capisci bisogna 
te lo faccia spiegare da qualcuno che ha tempo e voglia di farlo.


 te lo faccia spiegare da qualcuno che ha tempo e voglia di farlo.
Per me una affermazione in linea generale non serve a niente in una 
discussione.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/macross-frontier.html

 discussione.
Però scusa, senza polemica, scrivi:
- ""in linea generale" l'affermazione [...] non puo' essere ne 
verificabile ne confutabile";
- "in linea generale qualsiasi affermazione è vera e falsa allo stesso 
tempo" [affermazione logicamente non corretta, ma non entriamo in 
ulteriori dettagli];
- "se tu porti esempi concreti uno potrebbe sempre dire che potrebbero 
essere casi isolati e l'affermazione non verrebbe confutata".
Mi sembra che si stia un po' slittando verso il paralogismo (o meglio: 
nel sofismo puro ;) ): l'affermazione generale non è valida perché manca 
di dettagli, i dettagli/casi non sono validi perché riguardano solo 
parti dell'affermazione.
...mah?!...
Di solito, senza voler nulla insegnare a nessuno, prima si osservano i 
fatti, i dettagli, poi da questi si ipotizzano delle affermazioni 
(generali, diverso da assolute) che vanno verificate con altri fatti. Se 
questi non confutano l'affermazione generale la si ritiene valida, sino 
a prova contraria.
:)
Ciao,
Paolo

 a prova contraria.
Perché deve essere ritenuta valida?
Tocca a chi fa un affermazione di dimostrare se è valida o meno.
Gli altri possono solo dire: "Potrebbe avere ragione oppure no".
Io posso dire che su Urano c'e' vita, ma gli Uraniani si nascondo i 
terrestri perché gli stiamo sul culo.
La puoi verificare? No.
Mi puoi smentire? No.
La prendi per vera fino a prova cotraria? Spero di no.


 terrestri perché gli stiamo sul culo.
che stronzi sti uraniani ...
-- 
Davide Consonni

 Mi puoi smentire? No.
Perché è un'opinione, non un'ipotesi :)
La differenza? La mancanza di dati, se fossero presenti potrei 
verificarla e, eventualmente, smentirla.
Ciao,
Paolo
P.S.: se andiamo un po' più OT gli Uraniani ce li lasciamo alle spalle... :D

 verificarla e, eventualmente, smentirla.
Sì è un opinione. E' un opinione formulata come se fosse un'affermazione.
Il mio punto è che non ha senso trattarla come un'affermazione.
Secondo me ha poco senso dire: "ha ragione fino a prova contraria" 
oppure dire: "è falsa".


Concluderei l'OT citando Palmiro Cangini:
"... e con questo cosa voglio dire?
Non lo so! Pero' c'ho ragione!
E i fatti mi cosano!"


 E i fatti mi cosano!"
:D

 La prendi per vera fino a prova cotraria? Spero di no.
mi indichi per favore dov'è che è stata fatta una affermazione così 
stupida da meritare questo paragone? la frase da cui è partita questa 
(imho folle) discussione era assolutamente pertinente, si può essere o 
meno d'accordo ma ti ricordo che tu non ti sei posto il problema di 
confutarla, bensì il tuo problema è stato discutere che quella 
affermazione era stata fatta "in linea generale".


 affermazione era stata fatta "in linea generale".
Ho mai detto che la tua frase non era pertinente?
Se controlli io ho risposto al post successivo che diceva riguardo alla 
tua frase:
 > E' molto più che falso.
Ha poco senso falsificare un'opinione in quanto le opinioni non sono 
falsificabili.
E in piu' senza argomentazioni non poneva neanche una base per 
confrontare le due opinioni contrapposte.


 Ho mai detto che la tua frase non era pertinente?
ma non era mia la frase!
scusa la franchezza, a questo punto il dubbio se ci sei o ci fai mi viene...


 ma non era mia la frase!
Scusa, scusa, mi sono confuso tra rootkit e n.n.


 affermazioni sono vere finché non sono smentite.
Scusa se te lo faccio notare ma nessuno ha detto questa cosa.
Sempre che tu non prenda un pezzo di frase, ne togli dei pezzi, ne 
incolli altri col risultato di ottenere quello che vuoi...
E, te ne prego, non replicare citando solo metà del mio discorso ;)
Parlare di ipotesi, tesi e dimostrazione è ben diverso dal parlare 
esclusivamente di ipotesi.
Ciao,
Paolo

 falsificabili.
Un P.S. per mia curiosità personale: :)
mi spieghi la differenza tra opinione e ipotesi (escluso l'ambito di 
applicazione)?
Ciao,
Paolo

 chi scrive il codice e chi gestisce e ottimizza il DB
Non centra niente con le stored procedure e il database, ma recentemente 
ho un problema di dove e come piazzare la logica: devo fare un insieme 
di applicazioni client (che comunicano con webservice) che variano piu' 
o meno leggermente nella logica di presentazioni e di business.
Disegnare il modello ad oggetti, sparpagliando la logica dentro i getter 
/ setter se si tratta di piccole cose, o dentro la view stessa (ma si 
tratta di if semplici come se dato A e' presente e vale X allora mostra 
anche campo B) oppure dentro i bean per la logica di business mi 
costringerebbe a grossi lavori di manutenzione e non solo.
A questo aggiungiamo che le regole sembrano essere molte abbastanza 
soggette a variazioni.
Ora la prima applicazione l'ho fatta cosi', sparpagliando le logiche di 
quel tipo. Ora siamo alla seconda e si presenta evidente il problema. 
Come procedere ora?

 manutenibili. 
Quali sarebbero questi sistemi / linguaggi (mi pareva che avevi parlato 
di linguaggi e piattaforme altrove ma non ne sono sicuro)?

 Come procedere ora?
sicuramente il fatto che usi il termine "sparpagliare" è indice che non 
hai fatto un gran lavoro di progettazione... :)
non posso entrare nel tuo caso specifico, ma fintanto ho utilizzato un 
modello a tre livelli con i dao orientati al database (con metodi che 
mappano l'accesso diretto alle tabelle), i manager orientati alla logica 
applicativa (con metodi che mappano le operazioni di business logic) e i 
model che mappano le richieste del view, l'ultimo dei miei problemi è 
stato proprio la manutenibilità (almeno per il problema di trovare il 
codice da manutenere, poi è ovvio che non c'è una singola soluzione a 
tutti i problemi). non solo, ma nel momento in cui voglio passare da 
spring a ejb3 o viceversa, oppure voglio pubblicare la mia logica in un 
web service, il costo è realmente zero. inoltre ponendomi l'obbligo (e 
ponendolo ai programmatori) di astrarre sempre una interfaccia anche sui 
dao, mi smarco dai vincoli di un motore di persistenza per 
l'applicativo: posso avere un dao che usa hibernate, uno che usa il jdbc 
nudo e crudo e anche un dao che ha due implementazioni diverse, poi se 
il manager usa uno o l'altro lo configuro in modo dichiarativo.
si può obiettare che per un progetto di piccole dimensioni sia 
sovraingegnerizzato, ma per quanto mi riguarda questo pesa solo sullo 
startup (e neanche tanto, una volta ti sei creato un archetype).


 Paolo


 Paolo



Rispondo qua ma ho letto tuttta la linea filosofica.
Accetto le critiche alla frase "In linea generale" poiche' e' poco
scientifica.
Modific l'affermazione:
Nella maggiore parte di ambiti applicativi scrivere parti di logica dentro
il database tramite stored procedure e similari e' architetturalmente
scorrretto e piu' gli applicativi sono grossi , complressi e distribuiti ,
piu' e' diventa un massacro per il team che ci lavora
1.
 Si vincola l'applicazione a una tipo di supporto dati, in questo caso
database, il che e' una limitazione forte perche se si volesse applicare la
BL a un altro tipo di dati non si dovrebbero replicare intere parti di
logica per gestire altri dati. Scorrettissimo.
2
Purtroppo oggi ci si vincola addirittura a un vendor.
Scorrettissimo.
3.
I Database per loro natura non sono linguaggi di programmazione e quindi
sono molto ma molto inferiori ai linguaggi OOP moderni in quanto ad
architettura delle applicazioni, manutenibilita', leggibilita'.
portabilita', integrabilita', eleganza.
Qquindi e' scorrettissimo scegliere di scrivere in un DB la logica se non
c'e' una esigenza sopecifica che ne giustifichi l'tilizzo .
4.
L'unico motivo per cui si puo' / si deve scrivere in un db sono le
prestazioni.
Poiche' pero' nel 90, anche 99% degli applicativi le prestazioni non sono un
problema si puo' dire che quasi sempre e' sconveniente scrivere logica in un
DB.
Aggiungiamo che poiche' le prestazioni negli anni stanno salendo
vertiginosamente, si puo' pensare che fra altri anni si avranno prestazioni
infinite ( tempi nulli di IO). A quel punto le stored procedure si
estingueranno come si sono estinte le schede perforate.
Il dato 90 , 99% non ha una fonte, e' una mia statistica personale che ho
verificato nella mia esperienza e che ecomunque e' supportata dal fatto che
le prestazioni crewscono cosi' tanto negli anni che quello che era lento
20/30 anni fa oggi ha avuto un aumento di X% gfrazie all'HW.
Qualora si fosse scritto 20 anni fa un progetto in Database per avere un
aumento di Y% potremmo facilmente verificare che X%>>Y%, quindi salvo casi
eccezionali non e' l'utilizzo dei DB come linguaggi che si risolve il
problema prestazionale e e prestazioni sono un falso problema.
Aggiungo per concludere che di solito java non viene utilizzato ancora per
applicazioni ad altissime prestazioi quali i videogames e quindi dire che in
java il problema prestazionale non e' molto sentito e' ancora piu' vero
rispetto ad altre piattaforme.
Ciao a tutti


 hai fatto un gran lavoro di progettazione... :)
Mi sa che hai letto solo l'ultimo paragrafo oppure non mi sono fatto capire.
Non credo che quando programmi un'applicazione web tradizionale NON 
tendi a sparagliare cose come
public int getFirstAndLastNAme() {
   return first + " " + lastName;
}
oppure
<h:inputText value="..." rendered="#{a ? true : b.c}"/>
I DAO, service ecc non sono fatti per contenere logiche di questo tipo.

 piu'.
Ma dai. Quella degli uraniani. Non so chi l'ha scritta.
Era la cosa piu' profonda che ho letta. Hanno tutte le ragioni di 
nascondersi agli umani soprattutto se gli umani sono esperti java.  ;<))))))
-- 
ac
y-1=x

 I DAO, service ecc non sono fatti per contenere logiche di questo tipo.
ma questi sarebbero esempi di business logic?
forse è meglio se fai un esempio più concreto, perchè forse si è vero 
che non ho capito e questi esempi non mi aiutano certo :)
per inciso, a mio avviso il primo è una proprietà transient dell'entità 
persistente, mentre sul secondo non vedo il problema...


 costringerebbe a grossi lavori di manutenzione e non solo.
Non sono sicuro di aver capito.
Tu hai un bean così (non scrivo i public):
class Person {
   String getFirstName() {...}
   String getLastName() {...}
}
Pero' hai bisogno anche di aggiungere
   String getFullName() {
     return firstName + " " + lastName;
   }
però non vuoi metterlo dentro il bean per motivi vari (costi di 
manutenzione, regole che cambiano spesso).
In questo caso fai un bean PersonView che esiste solo nella view che 
mima Person ma aggiunge la proprietà read-only 'fullName' calcolata al volo.
class PersonView {
   Person delegate;
   PersonView(Person delegate) {
     this.delegate = delegate;
   }
   String getFirstName() {
     return delegate.getFirstName();
   }
   String getLastName() {
     return delegate.getLastName();
   }
   String getFullName() {
     return delegate.getFirstName() + " " + delegate.getLastName();


 volo.
ufficio complicazioni affari semplici, eh... :)


 persistente, mentre sul secondo non vedo il problema...
Non ho capito. Cos'e' una "proprieta transient dell'entita' persistente"?
Se "transient" e' il transiente italiano mi sembra una contraddizione in 
termini. Fermo restando che non ho capito nemmeno per quale motivo "il 
primo" dovrebbe essere all'interno di una entita' persistente
-- 
ac
y-1=x

 
E ma se non puo' modificare il bean che puoi fare se no?


 Non ho capito. Cos'e' una "proprieta transient dell'entita' persistente"?
una proprietà annotata @Transient della @Entity persistente che 
definisce firstName e lastName.


 E ma se non puo' modificare il bean che puoi fare se no?
se proprio non può modificare il bean vorrà dire che nome e cognome li 
stamperà con due h:outputText invece che uno.
le soluzioni non possono essere più complicate del problema...


 le soluzioni non possono essere più complicate del problema...
Anche.
Dipende se deve farlo una volta o ennemila.
Se poi cambia la regola da Fullname = FirstName + LastName in FullName = 
  Lastname + FirstName.
Bisogna andare a scovare in tutti i posti hai fatto la concatenazione a 
mano.


 definisce firstName e lastName.
Va bene. Ma questa cosa in cio' che ha scritto cicap dove stava?
E comunque continua ad essere una contraddizione in termini.
Questa e' la prima volta che la vedo. Vabbe' non e' che sia un 
"conoscitore" di java (il  linguaggio). Visto che ci sei, quale 
"problema" dovrebbe risolvere questa notazione e cosa aggiunge in 
chiarezza e come serve per evitare "l'ufficio complicazioni affari 
semplici"?
O forse serve ad alimentarlo? ;<)
-- 
ac
y-1=x

 definisce firstName e lastName.
Nel caso specifico credo che sia sufficiente fare una proprietà readonly.


 O forse serve ad alimentarlo? ;<)
se vuoi discutere del sesso degli angeli hai sbagliato campanello.
ma non disperare, qualcuno disponibile c'è.


 ma non disperare, qualcuno disponibile c'è.
non v'e' alcun problema. Male che vada mi cerco un po' di letteratura.
-- 
ac
y-1=x

 Ho forse scritto che era *sbagliata*?.
peggio mi sento, così la polemica è ancora più gratuita.

 Nel caso specifico credo che sia sufficiente fare una proprietà readonly.
Ho detto una mezza stupidata.
Se crei una proprietà readonly devi digli che @Transient come dice, al 
solito giustamente, rootkit se no la JPA si arrabbia.
-- 
Andrea Francia
http://www.andreafrancia.it/

 che non ho capito e questi esempi non mi aiutano certo :)
Immagina di avere 'n' campi da visualizzare in varie pagine. In baso 
allo stato di alcuni di questi campi, altri campi devono essere 
visualizzati o meno, essere readonly o meno, avere certe regole di 
validazione o meno.
Ora immagina anche di avere 10 applicazioni da costruire in questo modo, 
con una struttura molto simile ma dove le regole variano leggermente 
l'una dall'altra. E dove all'iterno dello stesso progetto queste regole 
sono piuttosto mutevoli.
Tutte interrogano comunque lo stesso webservice (e non ho database).
Normalmente queste regole si piazzano dentro le proprieta' dei bean. In 
questo caso invece mi sembra un problema perche' avrei una merea di bean 
simili con regole diverse sparpagliate tra i vari getter / setter.
Inoltre avrei anche una marea di logica in pagina e, anche se si tratta 
di espressioni semplici, rende le cose piuttosto immantenibili.
Dopo un po' di ricerca mi sembra che invece di incastonare la logica 
dentro al domionio ad oggetti, sia il caso di rilassare tale 
infrastruttura (generalizzandola) e spostare la logica di presentazione 
e validazione dentro classi che implementano le regole.
A questo punto serve un motore che le richiama automaticamente nel 
momento giusto.
Sembra anche che una tale infrastruttura mi porti verso un rule engine 
(vedi Drools ad esempio), dove un giorno potro' sostitiure le classi di 
logica con regole scritte per tale sistema. Addirittura il webservice 
potra' fornire le regole che costituiscono la mia logica (visto che 
molte di esse servono anche a lui).

 stamperà con due h:outputText invece che uno.
Non sia mai ;)
#{user.firstName} #{user.lastName}
Grazie a Jacob Hookom...


Spiega questa citazione per favore.


 Non sia mai ;)
vabbeh ci siamo capiti :P


 Spiega questa citazione per favore.
Non e' una citazione ma un ringraziamento a Hookom, il creatore di 
Facelets. Egli ci ha sollevato dal dover piazzare componenti 
<h:outputText/> in ogni dove.


Capito grazie.
