di Riccardo Golia

Ieri ho fatto un po' di prove circa l'uso di alcuni dei nuovi controlli di Whidbey. Devo dire che mi hanno davvero impressionato i controlli per la gestione dei menù, del path di navigazione e la splendida tree-view. Se il tutto viene combinato con le masterpages, il gioco è fatto!

Con il meccanismo delle partial classes finalmente si rispetta il fatto che una pagina Web rappresenta un unico oggetto: questa è un'assunzione che solitamente viene fatta anche in fase di modellazione e progettazione. Una pagina è quindi una classe dove vengono inseriti sia gli elementi costituenti della UI, sia le azioni ad essi associate. Se ci si pensa bene, formalmente questo è decisamente più corretto rispetto all'approccio precedente del code-behind, dove interfaccia e metodi stavano in due classi diverse legate da un rapporto di ereditarietà.

Con il nuovo paradigma, se si deve progettare un'applicazione, la si può modellare individuando le pagine (e quindi gli oggetti) in funzione dei casi d'uso e rappresentarle tramite classi. Personalmente lo trovo un grosso e significativo miglioramento.

A queste riflessioni si aggiunge un'ulteriore constatazione: finalmente è possibile rispettare i contesti di visibilità per tutti gli elementi di una pagina. Mi è sempre piaciuto poco il fatto di dover definire come public o protected gli elementi dell'interfaccia all'interno della classe del code-behind. Ho peraltro sempre apprezzato lo sforzo fatto per separare il codice dalla UI. Con il nuovo paradigma vengono presi due piccioni con una fava: separazione UI/codice e corretta visibilità. Sempre parlando di contesto di visibilità, ci terrei infine a sottolineare un ulteriore aspetto: la possibilità di richiamare membri public delle classi relative alle masterpages nell'ambito delle pagine ASPX. Tramite la direttiva MasterType e l'oggetto Master è possibile esporre alle pagine "contenuto" informazioni della pagina master.