RICERCA IN ASP.NET CORE

SFRUTTARE IL MODEL BINDING PER RICEVERE L’INPUT DELL’UTENTE

Adesso andremo a vedere una parte molto importante ossia come ricevere l’input dai nostri utenti. Iniziamo a parlare del model binding che è un meccanismo basato su convenzioni, molto semplice e intuitivo da usare che ci consente di raccogliere l’input dell’utente e usarlo nelle Action dei nostri Controller.

Come abbiamo detto il model binding si basa su convenzioni, a posto di id potevamo scegliere un altro nome, l’importante è che il nome del template corrisponda al nome del parametro. Facciamo degli esempi.

Il cinque viene estratto grazie al RouteValueProvider e questa informazione in formato testuale viene convertita in un intero dal SimpleTypeModelBinder.

Il ComplexTypeModelBinder non solo crea l’oggetto ma ne valorizza anche le proprietà. Se arriva una richiesta a Courses, il QueyStringValueProvider non saprà come fare il binding con i parametri della Action, in questi casi possiamo fornire valori di default.

Id assumerà il valore quattro in questa ambiguità.

CREARE IL FORM DI RICERCA

Rispolveriamo la specifica.

Vediamo il piano per implementare la ricerca.

Vediamo una slide riepilogativa sul tag Form.

Questo è il codice della View.

IMPLEMENTARE LA FUNZIONALITA’ DI RICERCA

Un paio di punti già li abbiamo sistemati usando le convenzioni dei nomi e il model binder, vediamo la slide.

Non ci resta che fornire questa chiave ai servizi applicativi in modo che possano offrirci corsi pertinenti alla ricerca. Modifichiamo come prima cosa la classe AdoNetCourseService.

Si potrebbe fare in modo che quando non viene digitato alcun testo, la clausola WHERE non venga inserita. In realtà è il Query Optimizer che fa questo lavoro per noi.

Ora andiamo a completare l’altro servizio Applicativo, EfCoreCourseService.

RIEPILOGO

ASP.NET Core possiede un meccanismo chiamato model binding che si occupa di esaminare la richiesta HTTP per estrarre informazioni utili, così che poi possiamo usarle nelle action dei nostri controller. Si compone di due organi principali:

I value providers si occupano di estrarre i valori grezzi, in formato stringa, dalle varie parti della richiesta come route parameters, query string, form data e intestazioni;
I model binders si occupano invece di convertire quei valori grezzi nei tipi di dato che sono stati espressi come parametri dell’action.

Ecco, per esempio, una richiesta in cui è stata fornita una chiave query string page valorizzata su 5.

https://localhost:5001/Courses?page=5

Ed ecco l’action che gestirà tale richiesta, che riceverà il valore 5 dal suo parametro page di tipo int.

public ActionResult Index(int page)
{
//…
}

Senza che noi dovessimo far nulla, il valore 5 è stato recuperato dalla query string grazie a un value provider e poi convertito al tipo int da un model binder.

I model binder sono molto potenti e riescono a creare sia oggetti di tipo primitivo (come int e bool) ma anche di tipo complesso, come classi personalizzate create da noi. Quest’ultimo aspetto è molto importante, soprattutto quando realizzeremo maschere di modifica, perché ci permette di tenere coesi tanti valori in un unico oggetto.

Il meccanismo del model binding usa delle convenzioni di nomi ed è per questo che il valore fornito con una chiave querystring chiamata page può arrivare al parametro di un’action chiamato anch’esso page. Il confronto avviene in maniera case-insensitive.

In una richiesta possono esserci collisioni di nomi che possono portare ad ambiguità, come ad esempio una chiave query string chiamata page e un campo del form chiamato anch’esso page. In questo caso possiamo usare degli attributi per essere espliciti sulla fonte da usare per trarre il valore. Ecco un esempio in cui usiamo l’attributo FromQuery in corrispondenza del parametro page per indicare che il valore deve essere tratto dalla query string.

public ActionResult Index([FromQuery] int page)
{
//…
}

Ecco un elenco degli attributi che possiamo porre di fianco ai parametri dell’action:

FromForm attinge dai valori inviati con un form (metodo POST);
FromRoute dai parametri indicati nel route template (ad esempio l’id indicato in {controller}/{action}/{id});
FromQuery dalle chiavi query string;
FromHeader dalle intestazioni della richiesta HTTP. È necessario usarlo se vogliamo attingere valori da lì;
FromServices non attinge valori dalla richiesta ma dagli oggetti registrati per la dependency injection.

LINK AL CODICE SU GITHUB

GITHUB

Scaricare il codice della sezione13 o clonare il repository GITHUB per avere a disposizione tutte le sezioni nel tuo editor preferito.