Francesco Mele .com

So già che qualcuno penserà mooolto male di me leggendo quanto sto per scrivere. Anche io avrei pensato mooolto male di me fino a qualche tempo fa.

Il modello a 5 livelli prevede una netta separazione tra i vari strati software al fine di raggiungere il maggior disaccoppiamento possibile con le tecnologie dello strato attiguo.
Se per esempio usiamo MySQL come database, un buon approccio sarebbe evitare che lo strato di business utilizzi "qualcosa" tipico di MySQL; meglio ancora se poi gli oggetti di business nemmeno sanno se si accede ad un database invece che, per esempio, a web services.

Seguendo questa logica il modello a 5 livelli si divide nel modo seguente:

1. front
2. presentation
3. business
4. dao (Data Access Object)
5. model (di solito un DB o Web Services)

Ok, tutto bello, bellissimo.

Per essere drasticamente bravi ogni strato ha i suoi POJO (Plain Old Java Object, i bean semplicisemplici con soli getter e setter) perché, per esempio, una data presa da db è una java.sql.Date, ma alla business deve arrivare una java.util.Date, altrimenti il business conoscerebbe la tecnologia che contiene i dati. Un bean che utilizza la data sql è tipico del DAO (un bean di questo tipo viene chiamato "value object") che, al suo interno o tramite un helper, passa tutti i valori ad un bean dello strato di business (detto "business object", appunto).

Fu così che per anni ho scritto POJO su POJO con helper annessi che facevano sempre la solita, ripetitiva operazione di "trascolo" valori:
BO bo = new BO();
bo.setId(vo.getId());
bo.setName(vo.getName());
// ecc..
// da data sql a data di tipo util
bo.setDate(new java.util.Date(vo.getDate().getTime()));


e questo perché normalmente le entità che dovevano essere gestite in pagina erano mappabili 1:1 con tabelle del database. In questo caso spesso lo strato di business fa solo da passacarte.

Sono passati gli anni ed ho cambiato atteggiamento.
Quando

1. l'applicativo lo scrivi da zero
2. sai con estrema certezza che l'unico strato di dati sarà costituito da un database
3. sai con estrema certezza che il database sarà noto, versione compresa
4. non c'è separazione netta tra i componenti del team per cui alcuni accedono ai dati ed altri si occupano delle pagine

allora si può, e in alcuni casi si deve, utilizzare un'architettura a 3 livelli.
La motivazione è semplice: si risparmia tempo permettendo di concentrarsi sui problemi funzionali dell'applicativo.

I POJO allora diventano unici per tutto l'applicativo e potete chiamarli oggetti di dominio (infatti io li metto nel package "domain"); conoscono sia la data util che la sql, mappano direttamente le tabelle del DB ed arrivano direttamente in pagina senza troppi giri con buona pace di tutti, RAM del server compresa.

Quanto sopra, cioè l'approccio a 5 livelli, è quasi sempre riportabile ai progetti a cui ho lavorato. Direi che almeno il 90% dei prodotti software a cui ho partecipato risponde alle caratteristiche sopra esposte.
Insomma, avrei potuto risparmiare tante, ma proprio tante, ore spendibili in modi migliori, scrittura di codice compreso.