Forum Ubuntu-it

Dopo tante vostre indicazioni e dopo tanti progressi, mi appresto a creare la gestione dati ma stavolta non come nella rubrica, ma per un'applicazione più seria. Ecco come intendo fare, ditemi se sbaglio. Premetto: non userò servlet ma solo classi normali.

(1) Database -> (2) Driver -> (3) Classe di metodi elementari DAO -> (4) JSP intermedia -> (5) JSP visibile finale

1) Db mySql, che al limite quando la mia applicazione verrà deployata potrei anche fare creare in automatico se non dovesse essere presente;
2) Driver MySql che ho scaricato dal sito mySql, recentissimi, correttamente integrati nel mio programma;
3) Classi elementari di esecuzione query, connessione, disconnessione, update, delete. Sono piuttosto standard, me le ha passate un mio docente;
4) JSP intermedia, richiamata dalle JSP visibili ma essa non visibile, con i comandi per i vari tipi di dati specifici. Ad esempio, JSP per gli utenti del programma, JSP per gli studenti, JSP per i docenti, JSP per gli orari di lezione. Ogni JSP dovrà poi svolgere una specifica funzione, ad esempio inserire un nuovo utente o aggiornare i dati di un corso già presente. Saranno divise in cartelle, sotto webcontent, con ogni cartella relativa ad una tabella del DB. Richiameranno i metodi inseriti al punto 3.
5) JSP che non farà NULLA oltre a visualizzare qualcosa. Comunicherà con le JSP al punto 4.

Che ve ne pare? Se mi dite che è tutto ok il passo successivo (credo tra ALMENO qualche settimana!) sarà integrare la verifica aggiornamento in caso di più utenti che accedono in contemporanea (tramite Struts).

EDIT: mi sono accorto in questi giorni della becessità di gestire due eventualità. La prima riguarda inserimenti di righe con qualche campo vuoto (esempio, docenti senza telefono), la seconda la necessità di convertire caratteri accentati che vengono visualizzati in modo piuttosto pittoresco. Immagino che entrambi vadano gestiti al punto 4 giusto?

Non ho capito, vuoi fare prima tutto il JSP e poi in un secondo momento metterci dentro struts?

Quindi alla fine tra JSF e struts hai scelto quest'utlimo?

E perché allora non realizzare l'applicazione da subito con struts? Magari facendo prima un di prove/esercizietti con struts?

Un'occhiatina a grails glie l'hai data? (http://www.grails.org)

Dunque si, alla fine sceglierò Struts. TUTTI me ne hanno parlato benissimo. Solo che al momento mi sento inesperto e prima di mettere troppa carne al fuoco vorrei vedere se riesco a creare la mia applicazione senza. Poi lo studierò meglio, insieme anche ad altri componenti che mi avete consigliato in questi giorni (stampe ecc).

Ho diviso il mio lavoro in: per ora, una discreta padronanza con le nozioni di base arrivando ad un'applicazione almeno degna di tale nome; quindi (di questo ritmo tra una decina di giorni) studio approfondito di Struts ed anche degli altri componenti di cui mi avete parlato qui con prove varie ecc.

Per adesso andrò avanti con JSP. Vi pare che quanto ho scritto sia abbastanza corretto? Grazie come sempre

Premetto: non userò servlet ma solo classi normali.

???

integrare la verifica aggiornamento in caso di più utenti che accedono in contemporanea (tramite Struts).

???

condivido anche io quello che ti ha detto Massimo S. riguardo la necessità di partire subito con struts. Conta che, dal punto di vista della scrittura del codice, un'applicazione basata su struts è molto diversa da una realizzata in modalità "jsp centric".
Io poi nel DAO metterei solo l'apertura e chiusura della connessione, mentre in un'altra classe, che chiama il DAO, metterei i metodi di accesso. La connessione e i metodi di accesso sono due cose logicamente differenti.... Comunque cosa ritorna il metodo di accesso alla, credo, jsp? Il resultset? Invece crea delle classi che contengono le informazioni da visualizzare (campi privati e metodi set/get pubblici): nel metodo di accesso crei questa classe dal resultset e la ritorni alla jsp. Nel caso di liste, ritorna alla jsp sempre una collection: nel metodo di accesso per ogni elemento del resulset crei la classe di informazioni e la aggiungi alla collection. Poi nella jsp in modo molto semplice potrai iterare la collection, recuperando le informazioni nella classe specifica. Questo modo di impostare il software è semplice e chiaro ed è semplice da implementare successivamente.
ciao

ciao

[glow=white,2,300]Premetto: non userò servlet ma solo classi normali.[/glow]
Come non detto, userò le servlet. Anche se quello che proprio mi sfugge è: in quali casi e perché si dovrebbe usare una servlet al posto di una classe? Cosa offre in più?

[glow=white,2,300]integrare la verifica aggiornamento in caso di più utenti che accedono in contemporanea (tramite Struts).[/glow]
Beh uno dei vantaggi di Struts è quello di poterlo fare in modo semplice giusto? Anche se mi sa che per ora non lo userò (vedi dopo).

[glow=white,2,300]condivido anche io quello che ti ha detto Massimo S. riguardo la necessità di partire subito con struts. Conta che, dal punto di vista della scrittura del codice, un'applicazione basata su struts è molto diversa da una realizzata in modalità "jsp centric".[/glow]
PER TUTTI: Ieri sono stato alla Feltrinelli ed ho comprato un OTTIMO manuale di Struts, ve lo segnalo (Hoepli, Jakarta Struts, recentissimo del 2007, molto chiaro e completo). Oltre ad altri manuali su Java (io sono un affezionato dei libri su carta!). Ma proprio per la chiarezza del testo, mi sono reso conto che Struts non è una stupidata e merita di essere studiato molto a fondo prima di essere impiegato. Credo che la cosa più saggia ora sia buttarmi su JSP esercitandomi quotidianamente dal punto di vista prettamente pratico (ho studiato già un paio di libri di teoria, ma ho ancora tantissimo da imparare) e portare avanti un'oretta al giorno lo studio teorico di Struts seguendo il libro. Poi tra un mesetto questi due settori si incontreranno e potrò integrare le due cose, almeno questo è il mio piano di battaglia per febbraio.

[glow=white,2,300]Io poi nel DAO metterei solo l'apertura e chiusura della connessione, mentre in un'altra classe, che chiama il DAO, metterei i metodi di accesso. La connessione e i metodi di accesso sono due cose logicamente differenti....[/glow]
Capisco perfettamente. Parliamo del terzo livello, ossia le classi di accesso ai dati. Mi stai dicendo di sdoppiarle, mettendo in una i metodi connetti e disconnetti, in un'altra i vari metodi selectquerytostring ecc. Ma sempre metodi generici, non riferiti a tabelle del db. Tali metodi generici ("generici" non in senso informatico ma di funzioni!) saranno poi richiamati (istanziati!) dalle singole classi di competenza per i vari dati. Ad esempio, la classe relativa ai docenti istanzierà tali metodi per ottenere i docenti o per aggiornarli, ecc. Ho capito bene?

[glow=white,2,300]Poi nella jsp in modo molto semplice potrai iterare la collection, recuperando le informazioni nella classe specifica.[/glow]
Questo è chiarissimo.

[glow=white,2,300]nel metodo di accesso crei questa classe dal resultset e la ritorni alla jsp. Nel caso di liste, ritorna alla jsp sempre una collection: nel metodo di accesso per ogni elemento del resulset crei la classe di informazioni e la aggiungi alla collection.[/glow]
Perfetto. Cioé mi stai dicendo, istanzio una nuova classe di accesso ai dati specifica, ad esempio getDocenti, restituisco alla jsp un insieme di righe che visualizzo ad esempio con un ciclo di for. Giusto?

[glow=white,2,300]metodi set/get pubblici[/glow]
Aiuto! Mai usato questi tipi di metodi sinora, nel ciclo che vi ho descritto non ce n'è nemmeno uno! Dove usarli?

[glow=white,2,300]Questo modo di impostare il software è semplice e chiaro ed è semplice da implementare successivamente.[/glow]
Grazie! Sarà proprio quello che userò... Ora mi ci metto di buona lena!

Premetto: non userò servlet ma solo classi normali.

diciamo che non si capisce cosa vuoi dire. Servlet e classi sono due cose differenti. Mettiamola cosi' in modo semplice: le servlet servono da contenitore per usare le classi. Ma non è che l'uso dell'una pregiudica l'uso dell'altra. Ognuno ha il suo prorpio ambito di utilizzo.

ntegrare la verifica aggiornamento in caso di più utenti che accedono in contemporanea (tramite Struts).

Struts, all'interno del pattern mvc, si occupa solo del controller. L'implementazione che dovrai realizzare è solo lato DB, a carico quindi del model.

Credo che la cosa più saggia ora sia buttarmi su JSP

c'e' poco da studiare per le jsp. Servono solo per visualizzare informazioni e basta. C'e' poco da fare: una volta capiti i vari tag....finisce la'......Struts prima di tutto, secondo me.....e i tag di struts per le jsp.....

Ma sempre metodi generici, non riferiti a tabelle del db

no no, proprio metodi specifici. Potresti ad esempio ragionare per contesti funzionali. Uno di essi potrebbe essere quello dei docenti. Tutto dipende da quanti metodi ci sono: se sono pochi o relativamente pochi puoi utilizzare una sola classe di business logic, altrimenti crei tanti contesti funzionali (cartelle) in cui in ognuna crei una classe di business logic. Tale classe, quindi una o piu' di una, sono tutte uguali e al proprio interno contengono i metodi specifici: leggiDocente, inserisciDocente.....devi immaginare che il lato DB sia quello che fisicamente esegue le operazioni. Ragionare come se avessi davanti una black box: a me serve di inserire un docente, quindi non devo io a livello web sapere come fare per inserire e dove inserire. Richiamo un servizio che sa da solo il da fare: quello che c'e' da sapere è la signature del metodo, l'oggetto che ritorna e le varie eccezioni che potrebbero essere sollevate. Tutto qua. Non esistono, o non dovrebbero, metodi generici che ritornano un resultset. La logica di business è definita solo all'interno dei metodi di business. Esempio: in un metodo che torna una lista di oggetti, lista anagrafiche, io dal lato web non devo fare delle if o delle altre query per recuperare dei dati. Dal punto di vista web quello che mi interessa è avere una serie di oggetti gia' pronti: black box, quello che sa come reperire i dati e quali business applicare è solo il servizio lato DB. Il lato web chiede: a me serve questo e il lato business gli fornisce i dati gia' pronti.

istanzio una nuova classe di accesso ai dati specifica, ad esempio getDocenti, .

no. getDocenti sarà un metodo e non una classe di accesso. Poi l'iterazione di una collection avviene tramite un iterator e non un ciclo di for (non che non si possa fare con un for.....). Mettiamola cosi': se un metodo torna una String e hai la necessità in seguito di tornare anche un altro valore, dovrai apportare abbastanza modifiche al software. Se invece da subito torni una classe, aggiungerai solo il campo che ti serve nella classe senza modificare signature & company. Molto semplice. Per questo il ritorno deve essere una classe. Per cui nel tuo metodo getDocente, ottieni la connessione, esegui la query, recuperi le informazioni dal resultset, crei l'oggetto Docente, imposti gli attributi tramite metodi set pubblici che mappano la tabella implementando la logica di business, chiudi la connessione e ritorni l'oggetto appena creato. Nel caso di lista, fai le stesse cose per ogni occorrenza letta dalla query aggiungendo la classe creata, tramite metodo add(classe), alla collection.

metodi set/get pubblici

Si. la classe che serve da filtro tra web e DB, contiene solo attributi privati/protected e metodi pubblici di get e set dei singoli attributi, e, meglio, che implementi la classe serializable.
Spero di aver capito le tue domande e che le risposte siano abbastanza chiare: ho cercato di rimanere sul pratico evitando nomenclature sicuramente piu' precise ma che lasciano il tempo che trovano.
A proposito, per le eccezioni, tasto dolente, come ti comporti? Se, esempio banale, nel metodo leggiDocente il docente non lo trovi nella tabella dei docenti, cosa fai per far sapere al web che non esiste e deve visualizzare un messaggio a video?

ciao

Archimede Pitagorico ha scritto: Come non detto, userò le servlet. Anche se quello che proprio mi sfugge è: in quali casi e perché si dovrebbe usare una servlet al posto di una classe? Cosa offre in più?

In Java (quasi) tutto è un oggetto, e un oggetto è di una data classe. In un certo senso la classe è "il tipo" dell'oggetto.
Quindi in Java si usano sempre classi! Anche le servlet sono classi!

Quindi se si parla indistintamente di classi, si sta sul generico; se si parla di serlvet si sta parlando nel particolare di una certa tipologia di classi.
Penso che ha poco senso domandarsi la differenza tra classi e servlet, perché si fa una confusione di livelli, tra generale e particolare.

Venendo allo specifico, stiamo parlando di sviluppare applicazioni Web, e quindi non c'è niente da fare, possiamo girare la frittata ma alla fin fine c'è bisogno di qualcosa che parla il linguaggio del Web ovvero il protocollo http (quindi deve sapere accogliere richieste http e sparare risposte http).
Nel mondo java questo si fa con un container Servlet/Jsp (come Tomcat) e con un insieme di Servlet che compongono la parte dinamica dell'applicazione Web.
Le servlet servono per forza, infatti se vedi i metodi che hanno le servlet vedi che hanno un metodo per ogni metodo http (scusa il gioco di parole) che prende come parametri una richiesta e una risposta http.
A quel punto uno potrebbe decidere di usare solo un'unica servlet, ma otterrebbe uno schifo di applicazione perché monolitica e non manutenibile, nessuno sano di mente farebbe una cosa del genere.
Quindi si ha un insieme di servlet, ma si potrebbe decidere di inserire tutto il codice nei metodi delle Servlet, ma anche questo (a meno che non si sta facendo HelloWorld) sarebbe stupido, poco elegante, poco manutenibile ecc..
Normalmente si creano classi che trattano aspetti specifici della logica applicativa o si usano classi di librerie terze parti. In altre parole le servlet si occupano dell'interfaccia gestendo richieste e risposte ma delegano compiti specifici ad altre classi.

Forse ora ti starai domando: e le jsp? e struts? e JSF? come rientrano in questo schema delle cose.
La risposta è che sono uno strato costruito sopra le servlet (forse struts e JSF non sono solo questo o non tanto questo, ma le jsp sicuramente si). Infatti ogni jsp che scrive viene per prima cosa automaticamente convertita in una servlet dal container.

Allo stesso modo di uno che per scrivere un software, può decidere di farlo in linguaggio macchina, in assembler o in un linguaggio ad alto livello, cosi uno che vuole fare una Web-application in java può decidere di usare le servlet (più altre classi), di usare le jsp (più altre classi), o di usare qualcosa di più alto livello o una combinazione delle varie cose.

[glow=red,2,300]In altre parole le servlet si occupano dell'interfaccia gestendo richieste e risposte ma delegano compiti specifici ad altre classi.[/glow]
E CON UNA FRASE SI CHIUDONO GIORNI DI DUBBI. CON UNA SOLA FRASE MI HAI FATTO CAPIRE.
Servlet e classi sono simili nel senso che anche le servlet sono classi; servlet e classi contengono metodi, campi ecc. Solo che, e questo è il punto, le servlet avendo metodi get e post al loro interno si prestano di più ad interfacciarsi direttamente con le pagine jsp. Quindi lo schema ottimale, non obbligatorio ma ottimale è:
JSP -> SERVLET -> EVENTUALE CLASSE GENERICA
La Jsp istanzia una servlet per getire le informazioni da mostrare in output, la servlet nel caso di funzioni particolari potrebbe avvalersi di classi non servlet istanziandole. In questo caso una classe normale va benissimo, visto che tali classi non verrebbero istanziate da pagine jsp ma da servlet.

[glow=red,2,300]Penso che ha poco senso domandarsi la differenza tra classi e servlet, perché si fa una confusione di livelli, tra generale e particolare.[/glow]
Ovvero, le servlet sono particolari classi che per la loro struttura ben si prestano a dialogare con pagine jsp.

[glow=red,2,300]A quel punto uno potrebbe decidere di usare solo un'unica servlet, ma otterrebbe uno schifo di applicazione perché monolitica e non manutenibile, nessuno sano di mente farebbe una cosa del genere.[/glow]
Assolutamente d'accordo.

[glow=red,2,300]Quindi si ha un insieme di servlet, ma si potrebbe decidere di inserire tutto il codice nei metodi delle Servlet, ma anche questo (a meno che non si sta facendo HelloWorld) sarebbe stupido, poco elegante, poco manutenibile ecc..[/glow]
Certo. Perché infatti usare servlet anche laddove non ci sarebbe bisogno della loro particolare struttura?


Fin qui sono sulla giusta strada? Fatemi sapere, così vi scrivo anche le mie riflessioni sulla seconda metà della vostra risposta e vediamo se i miei entusiasmi sono giustificati! Grazie a tutti

Archimede Pitagorico ha scritto: [glow=red,2,300]In altre parole le servlet si occupano dell'interfaccia gestendo richieste e risposte ma delegano compiti specifici ad altre classi.[/glow]
E CON UNA FRASE SI CHIUDONO GIORNI DI DUBBI. CON UNA SOLA FRASE MI HAI FATTO CAPIRE.

Ah si!? Una sola frase!? Se lo sapevo ti risparmiavo il resto del pippone 

...le servlet avendo metodi get e post al loro interno si prestano di più ad interfacciarsi direttamente con le pagine jsp...

No, le servlet non si interfacciano con le jsp, si interfacciano con l'utente o meglio con il browser dell'utente.
Poi dire "si prestano di più ad ...", sembra quasi che sia così per caso 
Le servlet sono fatte a posta, volutamente, per interfacciarsi con un client HTTP tramite protocollo HTTP.

La Jsp istanzia una servlet per getire le informazioni da mostrare in output...

No, la jsp non istanzia una servlet, la jsp è una servlet, nel senso che quando crei o modifichi una jsp, la prima volta che l'utente tenta di accedere alla jsp il container automaticamente compila la jsp creando una servlet o meglio creando il sorgente java della servlet e poi compila anche quest'ultimo creando il file .class della serlvet. Successivamente l'utente interagirà con questa servlet.
Detto questo è anche possibile che una servlet (sia servlet fatta a mano, che derivata da una jsp) invece di rispondere direttamente ad una risposta HTTP demandi (in toto o in parte) la creazione della relativa risposta http ad un'altra servlet/jsp.

la servlet nel caso di funzioni particolari potrebbe avvalersi di classi non servlet istanziandole. In questo caso una classe normale va benissimo...

Qui sono d'accordo, solo non capisco su che basi classifichi le classi come normali o non normali. Secondo te le servlet non sono classi normali? Perché?

[glow=white,2,300]No, le servlet non si interfacciano con le jsp, si interfacciano con l'utente o meglio con il browser dell'utente.
Poi dire "si prestano di più ad ...", sembra quasi che sia così per caso  Wink
Le servlet sono fatte a posta, volutamente, per interfacciarsi con un client HTTP tramite protocollo HTTP.[/glow]
Chiarissimo. Avevo trascurato il ruolo intermediario di browser e pagine jsp tra utente e servlet/classi.

[glow=white,2,300]Qui sono d'accordo, solo non capisco su che basi classifichi le classi come normali o non normali. Secondo te le servlet non sono classi normali? Perché?[/glow]
Scusa, volevo dire servlet ed altre classi dove con altre classi intendo quelle che non possiedono già i metodi tipici della servlet, con i metodi post e get.


FIN QUI MI PARE TUTTO OK, CHE DITE?



[glow=white,2,300]no no, proprio metodi specifici. Potresti ad esempio ragionare per contesti funzionali. Uno di essi potrebbe essere quello dei docenti. Tutto dipende da quanti metodi ci sono: se sono pochi o relativamente pochi puoi utilizzare una sola classe di business logic, altrimenti crei tanti contesti funzionali (cartelle) in cui in ognuna crei una classe di business logic. Tale classe, quindi una o piu' di una, sono tutte uguali e al proprio interno contengono i metodi specifici[/glow]
Questo ultimissimo punto non mi è chiaro. Mi spiego.

Abbiamo detto che una buona struttura è:

(1) Db mySql -> (2) Driver mySql -> (3) Servlet gestione dati -> (4) Pagine jsp che richiamano le servlet.

ma, quesito sul punto 3. Se nel mio programma ho i settori docenti e studenti, e per ogni settore ho ad esempio i metodi inserisci e modifica, anziché inserire questi metodi in quattro servlet differenti (servletDocentiInserisci, servletDocentiModifica, servletStudentiInserisci, servletStudentiModifica) non mi conviene definire una classe con i metodi "di base" metodoInserisci(string query) e metodoModifica(string query) e poi due servlet che istanzieranno questi due metodi? Mi pare che così si risparmi codice!

Archimede Pitagorico ha scritto: FIN QUI MI PARE TUTTO OK, CHE DITE?

Ok, diciamo OK

Per il resto del tuo post, mi pare che l'interlocutore sia prampa, lascio la parola a lui...

BENISSIMO, non puoi immaginare i passi da gigante che mi avete fatto fare oggi. Si brancola nel buio, poi ad un certo punto inizi a collegare varie cose che avevi recepito qua e là, ne capisci il senso e tutto è più chiaro!

Aspetto l'ultimo punto allora! Grazie ancora

Sono a pezzi, nonostante i due moment presi per il mal di testa. Ma non mi fermo, incoraggiato anche dalla vostra disponibilità che mai avevo riscontrato in "altri" ambienti. Ho appena scaricato dalla rete un sorgente in Java enorme. Ho isolato i punti di mio interesse, e li ho analizzati. Molte cose mi sono chiare. Da questo momento potete anche considerare solo questo ultimo messaggio in quanto riassuntivo anche degli altri.

Tornando al nostro schema,

(1) db > (2) driver > (3) classi gestione dati > (4) pagine jsp finali

il problema riguardava il punto 3. I dubbi, soprattutto certe classi con metodi get e set e le modalità intrinseche di gestione dati, sono quasi risolti. Espandiamo quindi il punto 3. Ho capito il significato dei metodi get e set. Questi metodi si trovano in particolari classi, chiamate Bean e distinte per tipi di dati (ci sarà la bean docenti, la bean allievi ecc). Questi bean definiscono (scusate il termine) dei contenitori, delle scatole. Ed i metodi get e set mi danno la possibilità di riempire le caselle di queste scatole o di prelevarne il contenuto. Se non li implementassi, dovrei definire ogni singola variabile String nelle Servlet, e questo per ogni campo del mio database, rendendo la servlet pesantissima. Così invece basta che ad esempio imposto ad esempio docentibean.setcognome = Rossi (esempio) ed in una riga il gioco è fatto. Quindi esplodiamo il punto 3 in modo stavolta non tanto esemplificativo ma vicino alla realtà:

(3a) Classe gestione connessioni, separata dalle altre.
(3b) Classe metodi generici, tipo eseguiquery eccetera.
(3c) docentibean, che definisce i vari metodi get e set
(3d) Servlet clienti, che servendosi di c ed utilizzando a e b esegue le varie operazioni sui dati.

A questo punto, se fin qui ho capito tutto, la cosa più grande che possiate fare per me sarebbe (ovviamente solo se l'avete già pronta) inviarmi una semplicissima applicazione, ovvero una rubrica con nome e telefono, con metodi di eliminazione, aggiunta, aggiornamento. Sono arrivato ad un punto in cui il miglior sistema per imparare sarebbe proprio "analizzare col lanternino" una simile applicazione, ben distante da quella complicatissima che ho scaricato oggi dalla rete. Ve ne sarei davvero grato. Grazie e buona serata a tutti.

Per il resto del tuo post, mi pare che l'interlocutore sia prampa, lascio la parola a lui...

Ma io non mi offendo mica.....anzi... (b2b)

non mi conviene definire una classe con i metodi "di base" metodoInserisci(string query) e metodoModifica(string query)

secondo me, non è il web che dice al lato db "fai questa cosa in questo modo", in altre parole per l'inserimento usa questa insert. E' il lato server che deve essere in grado da solo di eseguire l'inserimento di un docente nelle tabelle. Potrebbe succedere, solo per esempio, che oltre la tabella dei docenti si debba inserire un'occorrenza su un'altra tabelle, aggiornare un campo da un'altra parte e recuperare un valore da un'altra tabella ancora .....e che il web deve sapere tutte queste cose? Assolutamente no. Il web chiede ad un servizio di inserire un docente fornendo, questo si' lo deve sapere lui, i dati del docente: poi quello che accade per l'inserimento non è di sua competenza. In questo caso il web si comporta da client rispetto al lato DB, ma potrebbe nascere l'esigenza di creare un'applicazione desktop, o un servizio webservices, o chissa che altro che debba inserire un docente. Che succederebbe? tutti i client dovrebbero essere a conoscenza di tutti questi passi? No. Tutti i client, importando il jar del lato DB al proprio interno, invocherebbero il metodo inserisciDocente fornendo i dati del docente, ognuno relativo al proprio contesto. (ecco perche' il lato DB potrebbe essere un progetto a parte per la creazione di una libreria jar). Anche perche' c'e' da considerare l'aspetto transazionale: chi da la commit? se la connessione la apri, inserisci e poi chiudi la connessione, come fai con altre eventuali operazioni successive a tornare poi indietro?
Ripeto, questo secondo me: poi nessuno vieta di creare i metodi inserisci (String query), aggiorna (String query), query (String query)  nell'oggetto DAO e richiamarle da dove vuoi.
Quello che io farei (ma non è legge, assolutamente.......) è:
1) classe DAO, con set (privato), get e chiudi connessione
2) classe BUSINESS, anche una sola, che istanzia il DAO e contiene tutti i metodi inserisciDocente(classe) , inserisciStudente (classe), aggiornaDocente(classe) - ma le eccezioni? cosa pensi di fare? (E' chiaro che non deve essere la BUSINESS esposta come public verso il lato web, ma va bene lo stesso: come so benissimo anche che con tomcat esisterà un solo war che include tutto al suo interno....).
3) la/e jsp destinate a richiamare i metodi CRUD, potrebbero richiamare una sola servlet di switch, cioe' che in base all'azione scelta dall'utente (campo nascosto nel form che indica la funzione), smista l' esecuzione ad una servlet specifica. Quest'ultima servlet potrebbe anche essere una sola che istanzia la BUSINESS, decide di controllare i campi digitati in maschera e quale metodo della BUSINESS invocare. Il tutto chiaramente utilizzando classi di passaggio dati tra il web e il DB.
Come vedi, alla fin tutto questo gran parlare non mi sembra che complichi la programmazione: pero' a questo punto si sa sempre "chi fa cosa"....e non è poco.....
Non so se ho dimenticato qualcosa, non ho ricontrollato ...boh..vediamo....per ora tutto questo scrivere mi ha fatto venire fame di dolci.....
Appena posso, ma comunque ci vuole poco tempo, ti creo una semplicissima applicazione di rubrica telefonica e poi ne discutiamo....per realizzarla, se ho ben capito, niente struts ma solo servlet/jsp. Giusto? Pero' io uso eclipse....ci sono problemi? credo di no.....
ciao e a dopo.....

Confermo, niente struts. Ed anche in Eclipse va benissimo (il mio unico problema è lo studio del programma, posso farlo anche da un blocco note). Ti ringrazio tantissimo, aspetto il mini - applicativo per studiarmelo a fondo!

Rieccomi al pc. Ci resterò per tutto il pomeriggio e forse stanotte. Appena dovesse esserci quel piccolo applicativo, sono pronto per studiarlo. Grazie Prampa!

forse per stasera ce la faccio....

Grazie, starò qui tutto il tempo.

Intanto ho capito un'altra cosa dei bean; servono a diminuire il continuo dialogo tra db ed applicazione (fanno da intermediari) snellendo così il carico di lavoro; anziché dialogare continuamente col db, l'applicazione popola un bean; da questo bean richiamerà i dati necessari; il bean dialogherà poi col db solo in occasione di modifiche ai dati. Potere di Google e della libreria, che sto depredando! Mi sono quasi rifatto lo scaffale. Quindi credo che (correggimi se sbaglio) in qualsiasi applicazione fatta per bene dovrebbe essere:

(1) Db -> (2) Driver -> (3) Classi DAO padri -> (4) Servlet con classi DAO figlie -> (5) Bean -> (6) Pagine jsp

Ci ho visto bene? Grazie a tutti!

Prampa una cosa importante.

Ieri ho scaricato un'applicazione immensa ed ho trascorso ore piccole a barcamenarmi tra montagne di servlet lunghissime. Mi faresti davvero un regalo mostrandomi una gestione dati ideale ma con un applicativo piccolissimo, bastano solo i campi "cognome" e "telefono" (con quello che ci sta dietro, servlet, bean, classi di query, metodi e connessione ecc). Non so come ringraziarti. Con quell'applicazione potresti darmi l'aiuto che in ore passate sui libri non ho ancora trovato.

Ragazzi i miei sforzi sono giunti al limite.

Dalla maxi applicazione che ho scaricato non riesco più ad andare avanti. Mi ci perdo. Ormai sono nelle vostre mani, è troppo complessa. Non riesco nemmeno a seguire le linee di codice per capire dove portano. Mi è tornato il mal di testa così l'ho eliminata.

(mad)  ::)  >:(

Spero di poter capire meglio con il programmino di Prampa. Grazie di tutto e buona serata!