Chiunque ti abbia detto di usare un'architettura a tre livelli ha chiaramente qualche malinteso sul termine e ti ha passato questo malinteso. Livelli descrive una separazione fisica tra le parti di un sistema, i livelli descrivono una separazione logica. Quello che cerchi è un'architettura a livelli, lo stai già utilizzando a due livelli.
Una tipica applicazione a tre livelli è costituita da un livello di presentazione (applicazioni web, mobili o desktop), un livello logico aziendale e un database / spazio di archiviazione livello (SQL Server, MySQL, NOSQL). Ciò è valido per le applicazioni che espongono la loro logica a più client tramite i mezzi di un'API pubblica. La rete StackExchange può essere vista come un'architettura a più livelli.
Un'applicazione multilayer sarà strutturata, concettualmente, allo stesso modo di una multitier, con l'importante differenza che alcuni dei livelli (presentazione, logica aziendale, accesso ai dati) possono risiedere all'interno dello stesso limite fisico (livello), ad esempio come assembly o un'applicazione WebForms ASP.NET.
Il problema principale che hai nell'applicazione è che non hai una chiara separazione tra il livello di accesso ai dati, il livello della logica di business (che può essere omesso se stai semplicemente presentando alcuni dati da un database) e il livello di presentazione, quindi il suggerimento che hai ricevuto. Il tuo livello di presentazione dovrebbe essere ignaro del livello di persistenza. Si suppone che si astragga la parte di accesso ai dati del codice dietro una classe o un'interfaccia. Questo ti darebbe la separazione logica tra la presentazione (la pagina web) e l'accesso ai dati (la classe / interfaccia).
Un altro problema che potresti avere è che all'interno della stored procedure potresti avere delle regole aziendali che normalmente risiedono nel livello della logica aziendale. Le opinioni su questo sono divise e la decisione su dove collocare queste regole dipende da molteplici fattori.