[Java] Applicare design pattern (J2EE Pattern Catalog)

[InformaticoRC]

ciao a tutti !!
Ho da qualche tempo a che fare con la manutenzione di un sistema software realizzato interamente in java. Sto curando la parte server e vorrei migliorare il sistema con l'applicazione di alcuni pattern a livello di presentazione, di business e di integrazione (J2ee pattern catalog http://www.corej2eepatterns.com/Patterns/) visto che è la prima volta che mi rapporto a questo tipo di cose... vorrei che mi aiutaste a capire qualcosina :)

il sistema già prevede un controller che centralizza la gestione delle richieste e l'elaborazione delle view...ora se io volessi utilizzare una servlet front strategy per migliorare la gestione (navigazione, elaborazione, dispatch..) come dovrei fare non essendo la mia un'applicazione web? e avrebbe senso una cosa del genere?
grazie per il prezioso aiuto :)

[marco.r]

Il pattern da utilizzare è il punto di arrivo, non quello di partenza. Tanto per cominciare che problemi ha l implementazione attuale ? Cosa vorresti ottenere ?

[InformaticoRC]

grazie per la risposta innanzitutto! Mah problemi di gestione non ne ha , visto che dicevo che è implementata una classe con il main che controlla il tutto..però vedo che con il front controller e con la servlet ci sono risultati migliori in quanto a gestione delle richieste..perciò ha senso applicare un pattern del genere? in più ripeto la mia non è un'applicazione web e ovunque trovo codici che interessano il processo di richiesta/risposta tra client e server web ..

[InformaticoRC]

Nessuno? :(

[Daniels118]

Ma di che tipo di applicazione si tratta? E' un server, un programma interattivo, o un batch?

[InformaticoRC]

Server ;) l'utente memorizza determinati dati in un DB integrato con l'applicazione stessa in modo da garantirne la portabilità.

[Daniels118]

Rileggendo c'è qualcosa che mi sfugge... hai detto che la tua non è un'applicazione web, ma poi fai riferimento a concetti più o meno legati a quest'ultimo (server, servlet, navigazione), quindi credo che sia necessario fare un po' di chiarezza su cosa esiste adesso e su cosa vorresti ottenere.

[InformaticoRC]

si giusto.. quello che non ho precisato è che il sistema consiste di due parti..una parte server e una parte mobile, il server, gestito da un operatore che inserisce determinati dati, inoltra i dati al mobile. ora ciò che a me interessa non è questo passaggio qui..ma solo e soltanto la parte "server" ..migliorare il sistema in termini di gestione delle richieste ecc(come scritto sopra) intendendo la stesse attività e funzionalità attivate dall'operatore (inserisce -modifica-cancella dati) in quanto,come dicevo, è implementato un controller che centralizza tutte le operazioni .quindi nel momento in cui si fa partire il sistema è il controller che permette di visualizzare la home, e tutte le schermate e che contiene le funzioni di inserimento dei dati in db, modifica, cancellazione dei dati che sono memorizzati in db, che permette l'inoltro dei dati mobile.

perciò studiando il concetto di front controller e servlet ho messo in rapporto queste due situazioni..e mi chiedevo (questo è il motivo del topic) se la strategia servlet può essere messa in pratica anche in questo caso a scopo puramente migliorativo dell'attività del controller. ;)

[Daniels118]

Quindi se ho ben capito tu hai implementato la gestione di tutte le richieste in un'unica servlet.
A questo punto la tua richiesta è fondata, avresti sicuramente un vantaggio in termini di manutenibilità del codice applicando un pattern MVC. Ti consiglio di dare uno sguardo al framework Spring, che dovrebbe essere tra i più semplici da utilizzare.

[InformaticoRC]

Quindi se ho ben capito tu hai implementato la gestione di tutte le richieste in un'unica servlet.


A questo punto la tua richiesta è fondata, avresti sicuramente un vantaggio in termini di manutenibilità del codice applicando un pattern MVC. Ti consiglio di dare uno sguardo al framework Spring, che dovrebbe essere tra i più semplici da utilizzare.

Esatto..è proprio quello che vorrei ottenere..migliore manutenibilità :)

[InformaticoRC]

Ho dato uno sguardo al framework spring come mi hai suggerito..diciamo che come concetti teorici il discorso può essere anche chiaro..quello che trovo un pò difficoltoso è l'applicazione di questi concetti al codice del controller che già ho.. Visto anche che si parla praticamente sempre di apllicazioni web e non è il mio caso.. Diciamo che avrei paura di peggiorare il codice piuttosto che migliorarlo e farmi del male da solo...

[Daniels118]

Ma questo controller di cui parli come si usa? Voglio dire, tramite browser?
Oppure c'è un'applicazione dedicata?

[InformaticoRC]

Nono, il sistema prevede una cartella codice con tutte le classi implementate tra cui quella relativa al controller..utilizzando eclipse, si importa il tutto e si fa partire l'applicazione con punto di partenza la classe controller.

[Daniels118]

Si ma come si interagisce con il programma?
Utilizzi una shell?

Ad ogni modo, il pattern MVC si può applicare anche senza un'interfaccia web, il criterio è il seguente.

La parte Model è costituita da tutte le classi che modellano il sistema sul quel stai lavorando.

Tipicamente esiste una classe per ogni tabella del DB che gestisce le operazioni comuni di inserimento, modifica, cancellazione e consultazione; queste classi vengono chiamate DAO (Data Access Object). I DAO vengono utilizzati anche per altri origini di dati (es. file di testo, stream, ecc.).

Vengono poi realizzate altre classi chiamate BO (Business Object) che implementano la logica di accesso ai dati. Se per esempio il tuo DB è progettato in modo che per ogni record in una tabella deve essercene uno corrispondente in un'altra, una BO può essere implementata in modo da garantire questa duplicità (cosa che potrebbe sfuggire se si lavora direttamente sui DAO). Ovviamente si possono implementare logiche più complesse.
I metodi che espongono dovrebbero essere consistenti, nel senso che dovrebbero poter essere eseguiti singolarmente senza che i dati risultino compromessi.

DAO e BO fanno entrambi parte del Model, infatti spesso si vedono classi che fanno sia da DAO che da BO, sebbene questo approccio sia da evitare.

La parte Controller si occupa invece di ricevere i comandi dall'utente e di invocare gli opportuni metodi dei BO, quindi passa i risultati ad una View che li converte in una forma presentabile per l'utente; in base all'esito dell'azione un controller può invocare diverse view. L'utente interagisce sempre con le view, anche per inviare i dati al controller.

I controller e le view non devono implementare la logica del sistema che stai rappresentando, ma devono solo fare da interfaccia di input/output tra l'utente e i BO.


Ricapitolando:
- i DAO espongono i metodi di interazione con le origini dati;
- i BO espongono le azioni che si possono eseguire sul sistema;
- i controller ricevono le richieste dell'utente e invocano le opportune azioni dei BO, quindi passano il risultato alle view;
- le view formattano i risultati e li presentano all'utente.

Puoi realizzare questi 3 layer senza appoggiarti ad alcun framework, l'importante è aver ben chiaro quali metodi deve esporre ciascun layer.

[InformaticoRC]

bene.. il sistema in realtà è già strutturato in questo modo..distinguo il livello di presentazione, quello di business e quello di integrazione..ci sono le classi che implementano l'interfaccia utente, le classi che implementano i servizi del sistema e le classi che si interfacciano con il DB.. perciò sto giungendo a conclusione che non dovrei far altro.. diciamo che studiando pattern, design pattern ecc che portano miglioramenti per diversi aspetti (manutenibilità, riusabilità ecc) stavo vedendo se fosse possibili poterli applicare..solo per migliorare quella che è l'implementazione attuale che comunque già rispecchia quei canoni da te elencati ... in ogni caso ,grazie mille per le risposte !!!! ;) ;)