[FLUG] N-tier design
- From: "Lorenzo Bolognini" <lorenzo@xxxxxxxxxxxxx>
- To: "fanolug" <fanolug@xxxxxxxxxxxxx>
- Date: Sat, 3 May 2003 04:56:46 +0200
Mailing List del Fortunae LUG
=============================
Ok... vediamo se c'ho capito qualcosa di sto cacchio di design n-tier.
Prendiamo una classica app 5-tier:
- presentation GUI (browser, webtv, pda)
- presentation logic (HTML, VB -nel senso degli widget di vb-, Delphi,
wxWindows, GTK, QT)
- business logic (un qualsiasi linguaggio: PHP, VBScript, Python, ecc...)
- data access layer (ehm... ADO!!... o magari
http://pear.php.net/package-info.php?pacid=46 )
- database (uno degli infiniti RDBMS purché sia client-server...)
Teoricamente in un'applicazione veramente n-tier ognuna delle sue componenti
dovrebbe poter risiedere ovunque e per es. se voglio costruire una nuova
interfaccia alla mia applicazione web-based, chessò in VB ;-), non devo far
altro che riscrivere la sola presentation logic e interfacciarla al layer
sottostante.
Alcune considerazioni (in no particular order):
- per fare una roba del genere a livello di presentation logic devo usare
dei template (anche se l'uso dei template non fa automaticamente diventare
la mia applicazione n-tier) mettendo dei tag speciali che vengono *riempiti*
a runtime dai dati
- astrarre dalla tecnologia che controlla lo strato sottostante deve essere
fatto in modo indipendente dalla piattaforma/linguaggio (su Windows posso
rendermi indipendente dal linguaggio costruendo oggetti/server COM, su tutte
le altre piattaforme posso rendermi indipendente dal linguaggio richiamando
metodi con XML-RPC e costruendomi web-services che restituiscono dati in
XML... il top della vita, a quanto pare, detto da quelli che campano a pane
e buzzword, sarebbe trasformare l'XML che ricevo in HTML tramite XSLT)
- la business logic non stabilisce altro che la *procedura* cosa fare prima
di cosa, il flow... è il regista, il cuore dell'applicazione, la colla che
tiene insieme il tutto e si occupa di dargli una forma coerente
- il data access layer deve astrarre dal database sottostante e finanche dal
nome dei campi (basta parametrizzarli in qualche funzione???). E' questo lo
strato che si occupa della restituzione dei dati (idealmente in XML)
- il database non conta una mazza a questo punto... anche se, al contrario
di quello che si dice IMHO, sarebbe una cazzata incorporare parte della
business logic a questo livello utilizzando le stored procedures (legate a
uno specifico db... sebbene ADO riesca ad astrarre anche da quello)...
mentre può essere *corretto* e coerente a un design n-tier costruire delle
viste!
Correggetemi se non ci ho capito un cacchio... please!
Lo
--
Bill Gates : "No! Nel nostro software non ci sono bug significativi che un
numero significativo di utenti vuol vedere corretti."
Other related posts:
