Sviluppare la GUI di una applicazione, sia essa web o windows (non considero la shell), è fondamentale per vari motivi: primo fra tutti è la parte applicativa che il vostro cliente valuterà per prima (e probabilmente nel 99% dei casi dipenderà il successo dell'acquisto). Suona male dirlo, ma vale di più (commercialmente parlando) una applicazione bellissima an 1-tier piuttosto che una applicazione molto meno bella distribuita (n-tier).

Detto questo, si comprende quanto sia importante dare il giusto peso allo sviluppo della GUI. Ma che struttura ha il codice della GUI  (view)? Sostanzialmente ci sono due aspetti: logica del dato e logica di navigazione. Bene, molte applicazioni sono sviluppate con l'approccio di autonomous view, cioè di una view che contiene sia la logica di dato (non accesso al dato !!) che la logica di navigazione. Questo approccio ha un solo vantaggio: si sviluppa velocemente il prototipo. Presente però parecchi svantaggi: non è facilmente testabile, se la logica di navigazione si complica (es. edit-mode e readonly-mode, oppure se il dropdown list ha quel valore allora .....) diventa molto complicato il codice (quindi più difficilmente manutenibile), se cambia la logica di navigazione praticamente si deve ricominciare da capo.

In alternativa si può procedere verso due modelli alternativi: Presentation model o Model view presenter. I due si assomigliano abbastanza, infatti in entrambe i casi la logica di navigazione è esternalizzata su una classe ad hoc (presentation model e presenter rispettivamente). Fra i due approcci sinceramente preferisco la seconda in quanto è la classe presenter a dirigere (in modo centralizzato) la view. Ciò fornisce un vantaggio importante: se la view implementa un'interfaccia, allora probabilmente è possibile avere una stessa classe presenter sia per una view web, sia per una view windows e perchè no un mock object ;-)