Quando restituiamo un JsonResult da una action, il framework utilizza internamente JavaScriptSerializer per serializzare il nostro model. Questo avviene in contrasto con ASP.NET Web API, che sfrutta invece la libreria Json.NET.
In casi semplici, probabilmente non ci accorgeremo mai della differenza. Tuttavia questa situazione risulta particolarmente scomoda nel momento in cui abbiamo un object model condiviso tra MVC e Web API, nel quale magari abbiamo personalizzato le regole di serializzazione tramite gli attributi di Json.NET:
public class Person { [JsonProperty("name")] public string Name { get; set; } }
Per far sì che anche MVC usi questa libreria, l'unica alternativa che abbiamo è quella di creare un ActionResult personalizzato come il seguente:
public class JsonNetResult : ActionResult { public object Data { get; set; } public JsonRequestBehavior JsonRequestBehavior { get; set; } ... }
JsonNetResult è molto semplice e contiene solo due proprietà: una per specificare il contenuto del risultato, l'altra (per uniformità alla versione "ufficiale" JsonResult), permette invece di indicare se le richieste di tipo GET sono ammesse o meno.
Il cuore della classe però è costituito dall'override del metodo ExecuteResult:
public override void ExecuteResult(ControllerContext context) { if (context == null) { throw new ArgumentNullException("context"); } if ((this.JsonRequestBehavior == JsonRequestBehavior.DenyGet) && string.Equals(context.HttpContext.Request.HttpMethod, "GET", StringComparison.OrdinalIgnoreCase)) { throw new InvalidOperationException("GET Not allowed"); } HttpResponseBase response = context.HttpContext.Response; response.ContentType = "application/json"; if (Data != null) { JsonTextWriter writer = new JsonTextWriter(response.Output); JsonSerializer serializer = JsonSerializer.Create(); serializer.Serialize(writer, Data); writer.Flush(); } }
Il codice può sembrare corposo, ma in realtà è piuttosto lineare: una volta verificato se la richiesta è di tipo GET e se questa sia ammessa, non facciamo altro che impostare il content type corretto e poi sfruttare gli oggetti JsonSerializer e JsonTextWriter per scrivere sullo stream di risposta. Ovviamente perché questa classe compili, è necessario referenziare il package Json.NET tramite NuGet.
Quando usiamo la versione standard JsonResult in una action, abbiamo a disposizione il metodo Json che rende molto comoda la scrittura del codice:
public ActionResult MyAction() { var model = ... return this.Json(model); }
Se vogliamo rendere l'utilizzo di JsonNetResult altrettanto semplice, possiamo creare un extension method della classe Controller:
public static class JsonNetResultHelper { public static JsonNetResult JsonNet(this Controller controller, object data, JsonRequestBehavior behavior = JsonRequestBehavior.DenyGet) { return new JsonNetResult { Data = data, JsonRequestBehavior = behavior }; } }
A questo punto saremo in grado di utilizzare Json.NET in maniera del tutto analoga a quella "ufficiale":
public ActionResult MyAction() { var model = ... return this.JsonNet(model); }
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Creazione di plugin per Tailwind CSS: espandere le Funzionalità del Framework
Routing statico e PreRendering in una Blazor Web App
Cambiare la chiave di partizionamento di Azure Cosmos DB
Implementare il throttling in ASP.NET Core
Registrare servizi multipli tramite chiavi in ASP.NET Core 8
Hosting di componenti WebAssembly in un'applicazione Blazor static
Effettuare il deploy di immagini solo da container registry approvati in Kubernetes
Ottimizzazione dei block template in Angular 17
Effettuare chiamate con versioning da Blazor ad ASP.NET Core
Effettuare il binding di date in Blazor
Load test di ASP.NET Core con k6
I più letti di oggi
- Utilizzare Docker Compose con Azure App Service
- Utilizzare QuickGrid di Blazor con Entity Framework
- Modernizzare le applicazioni WPF e Windows Forms con Blazor
- ASP 3 per esempi
- annunciato #netstandard 2.1. .NET Core lo supporterà a partire da #netcore3, così come le prossime versione di #xamarin, #mono e #unity.il supporto per #netfx 4.8, invece, non ci sarà. https://aspit.co/bq2
- Steel Style CheckBox per Silverlight 4.0