ASP.Net e Pattern Observer in Pratica – Prima Parte

Ieri mi è stata chiesta una piccola consulenza relativamente ad un bug presente su una pagina web sviluppata in ASP.Net Web Forms e vorrei condividere con voi sia lo scenario sia la soluzione implementata così da approfittare per parlare del Pattern Observer.

Il Requisito

Implementazione di una pagina di ricerca dove sono presenti alcuni web user controls tra i quali uno in particolare si occupa di raccogliere l’input dell’utente per effettuare una ricerca tramite la pressione di un pulsante apposito (presente sullo stesso user control), l’operazione di ricerca deve in qualche modo essere notificata agli altri user controls presenti sulla stessa pagina che utilizzando gli stessi valori inseriti nel primo controllo dovranno filtrare e renderizzare i dati di dettaglio.

La Soluzione originariamente implementata

La soluzione originariamente implementata, ovvero quella che generava bug, lavorava più o meno così:

  • Creazione di 3 user control
    • Ricerca.ascx
    • ListaDettagli.ascx
    • Dettaglio.ascx
  • L’utente inputa una serie di valori (tramite TextBox, CheckBox, ed altri controlli… presenti nel controllo Ricerca.ascx);
  • L’utente Clicca sul pulsante “Cerca” (sempre presente nel controllo Ricerca.ascx);
  • L’user control nel gestore di evento associato al click del bottone “cerca” istanzia un oggetto preposto con tutte le informazioni inserite dall’utente e lo memorizza in sessione;
  • Nell’evento Load degli altri user control viene letto l’oggetto in sessione e se questo non è null allora viene utilizzato come filtro.

Le problematiche riscontrate

Quello che il cliente lamenta è che la ricerca funziona a singhiozzi… ovvero:

  • La prima ricerca non funziona mai;
  • La seconda ricerca funziona se non vengono cambiati i dati inputati per la ricerca;
  • Le seguenti ricerche filtrano i dati dei dettagli con i dati inputati dall’utente per la ricerca precedente.

..ma come mai? ..e soprattutto sono solo questi i problemi effettivamente portati dalla soluzione implementata? ..oppure ce ne sono altri che l’utente (o addirittura il pogrammatore) non sta considerando? Inoltre qual’è il grado di portabilità e/o di estensione delle componenti software sviluppate?

La motivazione del problema ed una soluzione apparente

La motivazione del problema è molto semplice, nel ciclo di vita di una pagina ASP.Net  l’evento Postback viene scatenato dopo l’evento Load, quindi quando i controlli di dettaglio leggono il valore dalla sessione (nell’evento Load) lo leggono prima che l’user control Ricerca.ascx lo inserisca in sessione durante il Postback!

A questo punto, individuata l’origine del comportamento anomalo, potremmo essere portati a pensare che posticipare la lettura dei dati della sessione in un evento successivo al Postback (per esempio il PreRender) risolva il problema… bè diciamo che l’anomalia relativa alla ricerca effetivamente scompare ma questa è veramente una soluzione? ..oppure è quella che più comunemente  nel nostro campo viene definita come una pezza su un’implementazione poco controllabile?

Mi spiace dire che purtroppo siamo nel secondo caso…

..e allora cerchiamo di capire insieme come i design pattern possano aiutarci nell’implementare una soluzione più elegante ed affidabile, vediamo a cosa serve e come implementare il pattern observer.

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...