Anche se spesso sono solo uno spunto per risolvere i problemi, alle volte i pattern, specie se si lavora in gruppo, possono fare bene soprattutto alla salute di chi collabora ad uno stesso progetto.

Conoscere i pattern è ormai, praticamente, un requisito di base per ogni buon sviluppatore web. A parte il parolone, un pattern è nient'altro che una serie di regole che documentano e schematizzano una soluzione ad un dato problema, per definire la quale di solito ha collaborato una comunità di persone. Servono per favorire l'utilizzo di un sistema comune tra persone differenti, oltre che per essere sfruttati, a loro volta, per costruirne di nuovi, basandosi su concetti già noti.

I pattern esistono da sempre e ce ne sono di specifici per il web. Probabilmente quello più famoso è il multi-layered, che è in genere implementato con il suo pattern derivato, il 3-layered. Il famoso pattern che prevede la separazione di logica, contenuti ed acceso ai dati su tre livelli (layer o tier) differenti. Probabile che finora qualcuno l'abbia usato senza sapere in realtà che è un pattern :)

Altro pattern usato spessissimo è il Model-View-Controller, che prevede la separazione del modello dalla vista e dal suo controllore. E' praticamente l'implementazione del code-behind con le classi di una libray che VS.NET ed ASP.NET mettono a disposizione. Ammetto di non amare troppo l'attuale modello del code-behind (per così dire... :) e che appoggio invece le "speranze" di Riccardo. Con le partial classes avremo il vantaggio di poter modificare un solo file per ognuno dei tre oggetti, ma di trattare la pagina come oggetto unico, mantenendo la separazione logica propria del pattern MVC. Vero è che uno dei vantaggi maggiori di questo approccio risiede nel poter creare moduli di testing automatizzato, utili se l'ambito in cui lavorano i vostri oggetti non si limita a quello web.

In questo periodo ho implementato spesso sia il Page Controller che il Front Controller.

Il primo è ad esempio alla base di un sistema mediamente complesso che sto tirando su in questi giorni insieme ad Andrea Zani per un cliente. Il concetto è che una pagina può fare da controller delle richieste, in maniera centralizzata, e decidere in base a diversi parametri qual è il rendering da restituire. Nel caso specifico, carichiamo in base a diversi parametri alcuni user control all'interno di una sola pagina centrale, che in realtà di logica ha ben poco, se non appunto l'autorizzazione ed il richiamo di altri oggetti.

Il Front Contoller pattern, invece, è alla base di questo blog e di molte parti di ASPItalia.com. E' l'utilizzare, all'atto pratico, un controllo ad un livello superiore, attraverso HttpHandler (e se serve HttpModules), perchè il Page Controller pattern è troppo "semplice" per l'implementazione che si sta facendo. Un tipico esempio di Front Controller Pattern sono i sistemi di URL rewriting o i meccanismi di autenticazione che ASP.NET ci mette a disposizione.

In ultimo tra i più usati c'è il Cache Pattern, il cui utilizzo è ovvio: si mettono in cache dei dati molto richiesti ma che cambiano non così spesso, in modo da evitare che vengano recuperati da un database o da altre fonti esterne (e quindi massimizzando la disponibilità del sistema). E' un pattern che uso anche troppo :) C'è anche una variante che in questo ultimo periodo è sempre più diffusa e che trovate documentata qui.

Insomma, questa è solo una piccolissima introduzione ai design pattern, che ho incominciato ad odiare ai tempi dell'università ed amare quando ho approfondito l'argomento.

Ce ne sono sia per il software che per l'hardware e conoscerli non fa mai male. Ovvio che dipende dal tipo di lavoro che fate, ma se parte del vostro pane quotidiano è il design di sistemi, allora conoscerli può aiutarvi a lavorare meglio.