Questa riflessione parte dalla domanda di un utente nel forum:

Ho l'impressione che questa perplessità sia parecchio diffusa e che, più in generale, ci sia parecchia confusione quando si parla di software architecture: spero che questo post possa chiarire un po' meglio alcuni concetti.

Iniziamo definendo, in termini strettamente lessicali, cosa si intende per "3-Tier", dato che la stessa Wikipedia non è affatto chiara nè precisa (sia in italiano che in inglese) contribuendo ad aumentare la confusione.

Architettura 3-Tier (o n-Tier)

Letteralmente si parla di "architetture a 3 o più livelli" per definire un modello che fornisca una separazione fisica dell'applicazione; in pratica si dice che un'applicazione può essere erogata usando un'infrastruttura complessa e diversificata, tipicamente usando più server, ciascuno dedicato ad una funzionalità specifica (fron-end, middleware, back-end, ecc.)
Una spiegazione più dettagliata di questo modello distributivo è disponibile sul sito "Microsoft patterns & practices Developer Center": Three-Tiered Distribution

In pratica ritengo che si dovrebbe parlare di "tier" in riferimento a qualcosa di "sistemistico", e non per architettura software in senso stretto.

Architettura 3-Layer (o n-Layer)

Le architetture a 3 strati (o più: il "3" è entrato nella concezione comune in quanto rappresenta la stratificazione più semplice ed utilizzata) sono un modello di organizzazione del codice applicativo basato sulla separazione delle funzionalità logiche. Tipicamente avremo:

• Presentation (PL): la visualizzazione dei dati e, più in generale, la rappresentazione dei controlli (forms, controlli di input, labels, ecc.) necessari per l'interfaccia utente
• Business Logic (BLL): rappresenta la parte principale dell'applicazione, definendo il domain model dell'applicazione, ovvero le entità (ad esempio: fattura, cliente, ecc.), le loro relazioni e le logiche applicative. Non deve contenere contenere alcun riferimento a come i dati saranno presentati all'utente o a come verranno salvati
• Data Access (DAL): contiene tutto quello che concerne la persistenza dei dati (database, tabelle, record, file system, ecc.)

Questo tipo di architettura ha principalmente il vantaggio di fornire una separazione logica così da aumentarne la manutenibilità, la scalabilità ed il riutilizzo.
Una spiegazione più dettagliata di questo tipo di architettura è disponibile sul sito "Microsoft patterns & practices Developer Center": Three-Layered Services Application

Model-View-Controller (MVC)

Questo pattern, introdotto solo di recente nel mondo .NET ma diffuso da tempo in altri ambienti, fornisce un modello per strutturare in modo organizzato le funzionalità relative alla UI e orchestrare l'accesso agli altri strati applicativi (BLL e DAL):

• Model: è l'insieme dei componenti che mantengono lo "stato": i dati e i metodi per accedervi. In pratica costituisce la logica applicativa o - IMHO preferibilmente - l'accesso al layer (separato) di BL
• View: deputato alla visualizzazione vera e propria dell'interfaccia utente per la presentazione dei dati
• Controller: gestisce le interazioni dell'utente con l'applicazione (tipicamente intercettando e gestendo gli eventi e gli input dell'utente), mediante accesso al Model e definendo la View corrispondente da presentare

MVC non contraddice quindi il modello 3-Layer, semplicemente è una delle possibili implementazioni di questo tipo di architettura; da un certo punto di vista possiamo addirittura vedere MVC come un'estensione dell'architettura a 3 strati, in quanto porta una separazione logica ulteriore nel livello di presentation.

MVC è dunque un'alternativa ai Web Forms di ASP.NET e, come tale, ha vantaggi e svantaggi.

Per quanto mi riguarda (non ne faccio mistero: il modello a forms ASP.NET non mi è mai piaciuto per tanti motivi) MVC ha solo vantaggi :-)