Il nostro primo Controller

Assodata dell’importanza del Controller, non si può iniziare ad approfondire quanto di materia ASP.Net Mvc con questa classe. Tutti i file con le varie classi contenenti i Controller vanno necessariemente posizionati nella cartella Controllers.

Affermazione questa vera, ma con la sua debita eccezione. Come ho scritto nel primissimo post, infatti, questo nuovo pattern sembra volerci far dimenticare quanto in auge per il modello a layer, quindi assembly separati per ogni elemento costituente la nostra applicazione.
Confortatevi. E’ la prima cosa che sono andato a vedere. Si può comunque fare in modo che i vari elementi MVC risiedano ognuno dentro al suo assembly separato.
Certo, questo rompe un pò le regole del gioco, rendendo meno semplice l’approccio ad MVC: tuttavia, dopo uno scambio e-mail avuto con un referente in Microsoft circa la mia idea, c’è anche da dire che questo modo di operare non è propriamente corretto. In effetti nulla vieta, e anzi viene consigliato lasciare tutto quello che riguarda MVC nel suo progetto e trasferire solo la business-logic in assembly esterni, richiamando poi i vari elementi di interesse come si è sempre fatto fino ad oggi. Ci sarà in sostanza un modo differente di concepire il progetto, ma il succo non cambia.

Indipendentemente che vogliate far risiedere tutta la classe controller in un assembly esterno o che ne stiate creando un nuovo nel progetto base, la nostra classe Controller deve avere una referenza all’assembly System.Web.Mvc.

La tipica classe Controller è così composta:

public class TestController : Controller
{
public ActionResult Index()
{
....
return View();
}
}

Una classe quindi che eredita dalla classe base Controller che il sistema si aspetta di trovare all’interno della cartella corretta.

Non ha importanza che la classe si interfacci al database o ritorni il classico Hello World.

Ogni singolo metodo o funzione della classe Controller di tipo ActionResult sarà una specifica azione a disposizione della nostra chiamata. Questo dovrebbe a questo punto rendere più chiaro la route di default e il fatto che l’action di default è impostato su Index, metodo che generalmente fa poco o niente.

Nel caso sopra, giusto per commentare, non farebbe niente, ma si limiterebbe a chiamare la relativa View contenuta nel seguente percorso ~/Views/Test/Index,aspx.

La mancanza del file appena menzionato, porterebbe inevitabilmente a generare un errore al sistema, che pur cercando il file Test/Index.aspx nei percorsi di default non sarebbe in grado di trovarlo.

Questo reindirizzamento è ovviamente controllabile. Il metodo View, infatti, dispone di diversi overloads, uno tra i quali con un parametro in grado di contenere il path virtuale completo di una vista verso la quale dirigere l’output.
Fare uso di questo parametro è ovviamente un rischio, perchè romperebbe le regole della semplicità e anche quelle di un legame gestito internamente dal framework.
Se infatti, un domani io rinomino la view di destinazione, tutto ciò che è stato scritto all’interno delle mie classi in forma esplicita non verrà aggiornato e questo porterà poi a futuri errori di run-time se non passo la mia applicazione ad una fase di test.

Questo è ovviamente il comportamento base della classe Controller. Ogni singolo metodo può comunque scegliere cosa far ritornare, così come di base ogni metodo pubblico della classe controller viene trattato come una possibile action, a meno che il metodo pubblico non venga decorato con l’attributo NonAction.

Technorati tags: ,