Trabajando con documentos JSON en .NET Core 3.x (I)
Introducción
Una de las mejoras incorporadas a .NET Core 3.0 ha sido el namespace System.Text.Json.
Este namespace tiene como objetivo principal, unificar y simplificar las tareas y acciones que sobre un documento JSON (JavaScript Object Notation), necesitamos realizar permitiéndonos romper con algunos problemas de dependencias, que el uso de diferentes versiones de Newtonsoft.Json (JSON.NET) desarrollada por James Newton generaba a otros desarrolladores y paquetes de terceros que lo usaban, incluyendo el propio Microsoft Azure.
Aunque existen diferentes librerías para trabajar en .NET con documentos JSON, la que cito es la más extendida y utilizada de forma global, y se ha convertido en casi un estándar a la hora de trabajar con documentos JSON en .NET.
Cabe mencionar también, que el mismo James está trabajando desde Marzo de 2018 en Microsoft, y dió su ok al fichar por Microsoft para permitir esta transición.
¿Debemos seguir utilizando en .NET Core 3.x Newtonsoft.Json o pasarnos a System.Text.Json?
Así que la primera pregunta que podemos hacernos es si conviene seguir trabajando con Newtonsoft.Json en .NET Core 3.x o si por el contrario merece la pena olvidarnos de él y pasarnos directamente a System.Text.Json.
Pues bien, aunque podríamos utilizar ambos, mi opinión es drástica al respecto.
Creo que no tiene mucho sentido utilizar paquetes, utilidades o librerías externas fuera de .NET Core si queremos trabajar con documentos JSON, como por ejemplo la comentada Json.NET ya que en .NET Core 3.x encontraremos lo que necesitamos para cubrir nuestras necesidades.
Y como segundo asunto, si vas a migrar tu aplicación a .NET Core 3.x y utilizas JSON, quizás sea buena idea además hacer un pequeño esfuerzo para eliminar la referencia a Newtonsoft.Json de tu proyecto y utilizar en su caso System.Text.Json.
Y es que este nuevo namespace como indico, cubre todas las necesidades que cubre otras librerías agregando además, una serie de mejoras en cuanto a la eficiencia y rendimiento que lo hacen más productivo si cabe.
¿Y qué sucede si trabajo en .NET Core 2.x o en .NET Framework 4.6.1 ó superior?
Aunque parezca que este namespace es sólo para .NET Core 3.x, conviene indicar que su aplicación se extiende más allá, ya que es posible descargar su correspondiente paquete System.Text.Json en NuGet para poder utilizarlo en .NET Framework 4.6.1 o posteriores, o en .NET Core 2.0, 2.1 ó 2.2, incluyendo igualmente soporte a .NET Standard 2.0.
¿Y en qué consiste realmente este namespace o qué mejoras incluye o porqué debería actualiar mis desarrollos para usarlo?
A modo resumen, este nuevo namespace tiene como propósitos principales serializar objetos a texto en formato JSON, y deserializar texto en formato JSON a objetos.
Otra de las mejoras incorporadas es la posibilidad de trabajar con modelo de objeto de documento en memoria (DOM) habilitando acceso directo a partes del documento JSON en modo lectura.
También cabe mencionar en este namespace el soporte directo a UTF-8, el cual tiene implicaciones directas respecto al rendimiento y una bajísima asignación de memoria.
El soporte directo a UTF-8 constituye mejoras adicionales con respecto a la optimización de leer y escribir JSON codificado como UTF-8 que suele ser usado en Web y ficheros.
Partes principales del namespace
Las partes principales del namespace quedan resumidas en la siguiente imagen (extraída del roadmap de Microsoft respecto a este namespace):
Tal y como vemos, el namespace tiene varias clases, pero de todas ellas destacaría dos especialmente por su frecuente uso:
JsonSerializer nos permitirá serializar objetos o tipo valor a JSON así como deserializar JSON en objetos o tipos valor.
JsonDocument nos permitirá examinar el contenido estructural de nuestro JSON sin instanciar los datos en sí.
Dentro de un JsonDocument encontramos la estructura JsonElement que representa un valor JSON concreto.
A modo resumen, convendría tener en cuenta que por defecto:
- Todas las propiedades public son serializadas directamente
- Los caracteres que no son ASCII y caracteres Web, deben ser escritos de acuerdo a la especificación JSON RFC 8259
- Los JSON generados están minimizados (no sangrados)
- Los nombres de un JSON son por defecto sensitivos en mayúsculas y minúsculas con respecto a los nombres de .NET
- Los valores null no son ignorados por defecto
Ahora bien, ¿cómo debemos utilizar este namespace?, ¿cómo debo o puedo migrar mis aplicaciones para utilizar este namespace?.
Lo mejor es verlo con sencillos ejemplos, algo que veremos en una otra entrada del blog.
Happy Coding!
