Newsgroup: it.comp.java
Titolo: EJB e metodo find

Ciao,
stousando gli ejb per scrivere una applicazione web, adesso mi trovo nella
condizione id voler creare un metodo find con un sql non supportato, è
possibile scrivere all'interno di un ejb cmp 2.x un metodo che faccia un
find andando a lanciare manualmente la select sul DB?
Ciao
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Che mi risulti no, l'unica cosa che puoi usare e il linguaggio delle 
query ad oggetti che ti fornisce il CMP. Comunque con quel linguaggio si 
riesce a fare praticamente tutto... Altrimenti devi passare a BMP!
Gian Luca


Io vorrei fare una query su MySql del tipo
SELECT * FROM TABELLA WHERE MATCH(CAMPO) AGAINST ('parola')
e mi sembra che non si possa eseguire attraverso ejbql



Se posso darti un consiglio, non utilizzare direttamente i metodi di find
degli ejb di tipo entity. Piuttosto, utilizza un EJB session (stateless,
magari) che restituisce una collection delle chiavi primarie (reperite via
JDBC da MySQL) con le quali poi puoi richiamare, con create, i tuoi entity.
Le prestazioni ne avranno grande beneficio.
Scorpio.


Il tuo consiglio č privo di qualsiasi fondamento, mi fa pensare che nemmeno
tu abbia ben chiaro in mente come funziona l'architettura J2EE (questa č
solo una mia considerazione, puň essere che mi sbaglio).
Il session Bean non deve assolutamente uscire fuori dai suoi compiti
realizzando la logica di ritrovamento delle informazioni attraverso JDBC per
vari motivi.
1) L'Entity Bean in esame č di tipo CMP, quindi non sai se la sua
persistenza č fatta con un DBMS relazionale che ti permetta l'utilizzo di
JDBC.
2) Anche se la persistenza č di tipo BMP, oppure sei certo che la
persistenza sia fatta utilizzando un DBMS relazionale, il session Bean non
deve sapere o non sa quale sia il nome della tabella che contiene i dati ne
quali siano i vincoli di dominio, di tupla o di referenza.
3) Se tu trovi i dati attraverso il session Bean e poi chiami la create per
ogni tupla questo non va bene perchč avresti un'eccezione di chiave primaria
duplicata, oppure potresti conservare gli entity bean cosě creati in
un'altra tabella, ma se un altro client richiede gli stessi dati avresti
comunque il problema della chiave duplicata, una soluzione potrebbe essere
di aggiungere un'altra chiave, ad es. un autoincremento, risolvendo cosě il
problema della duplicazione, ma cosě cambieresti la definizione dei dati.
4) Con la soluzione di cui sopra ad ogni richiesta dei client duplicheresti
dati e non riutilizzi quelli esistenti, quindi non sfrutti il resource
pooling e di conseguenza non aumenti l'efficienza.
5) Un'altra soluzione potrebbe essere che in caso di eccezione di chiave
duplicata allora utilizzi il metodo obbligatorio ejbFindByPrimaryKey, questo
ti farebbe utilizzare il resource pooling, ma il programma cosě ottenuto non
č efficientissimo ed č molto confusionario.
Queste sono solo alcune considerazioni da tenere a mente, comunque per
evitare tutti i problemi che ho elencato basta utilizzare ogni tipo di bean
per svolgere i compiti per cui č stato pensato, quindi l'entity bean deve
preoccuparsi di conservare i dati e deve fornire i metodi find per
ritrovarli, il session Bean deve sfruttare l'interfaccia dell'entity Bean
per lavorare su i dati e non deve farlo lui direttamente, come una buona
programmazione ad oggetti richiede.
Ciao gigabyte


Ciao,
  Scorpio

 [CUT]
Scusami se ti sono sembrato un po' duro o magari offensivo, infatti,
rileggendo il mio post sono parso attezzoso, non era mia intenzione.
Comunque io penso che non si deve utilizzare una tecnologia solo perchè è di
moda, infatti, se non hai bisogno di EJB non li devi utilizzare per forza.
Non mi sembra che in giro ci siano hosting che offrano Application Server a
buon mercato, ma è più facile incontrare Web Server che diano la possibilità
di sfruttare JSP o Servlet.
Credo che se si deve sviluppare una pagina web di tanto in tanto, a buon
mercato, e con poco tempo a disposizione si potrebbe fare tutto senza
ricorrere agli EJB. Bisogna ricorrere a questi solo quando ci sono
particolari esigenze, quali ad esempio: riusabilità del codice, modularità e
struttura robusta, ma questo credo sia utile solo per progetti di media o
grande importanza.
Personalmente per fare il sitarello che interroga il database uso la coppia
PHP + MySQL, perchè di hosting siffatti se ne trovano a prezzi stracciati e
per piccoli progetti i tempi di sviluppo sono brevi. Poi PHP incorpora
svariate funzione e utilità pensate proprio per il web e per query SQL, a
titolo esemplificativo basta pensare ai MAGIC QUOTES ovvero parole tipo "po'
" vengono memorizzate come "po\' " evitando problemi con la sintassi SQL,
cosa che non mi risulta venga fatta in automatico da Java e che se non si ha
malizia a volte lo si dimentica o diventa troppo oneroso occuparsene.
ciao gigabyte

 grande importanza.
Sono d'accordo. Gli EJB sono molto potenti, ma anche molto difficili da
imparare. E comunque, richiedono uno sforzo di progettazione che non è
giustificabile in progetti di piccolo respiro. Non posso sapere quale sia il
progetto che Pippo aveva in mente...magari è qualcosa di galattico. Magari è
un "esercizio" di programmazione.
Ma, per amor di discussione, quanti sono i progetti Java 'reali' che
utilizzano sistematicamente EJB ?
Io non ne conosco molti...
Ciao,
Scorpio.


Grazie per i consigli, alla fine pero' per la mia pagina di ricerca ho
scritto una servlet che si farestituire il DS ed effetua la select. Per
l'uso degli ejb devo dire semplifica abbastanza le cose. Ho lavorato ad un
progetto completamente ejb con una trentina di tabelle una delle quali con 3
milioni di record e devo dire che ne sono rimasto colpito in modo ottimo,
anche perchè nel momento in cui abbiamo avuto bisogno del cluster tutto è
stato semplice e quasi immediato, apparte qualche problema . Io avevo deciso
di usare ejb rispetto ad altre tecnologie piu' ligth tipo php perchè avevo
necessita del supporto delle transazioni a due fasi (XA).
Ciao e Grazie


 ha scritto nel messaggio
news:212Z210Z165Z146Y...@usenet.libero.it...
