Si sois habituales del blog, probablemente ya sabréis lo que os voy a decir ;)
Como todos los años por estas fechas, empieza el periodo vacacional y aprovecharé para bajar un poco el ritmo, descansar unos días y disfrutar de familia y amigos.
Por tanto, dejaré el blog en modo de bajo consumo hasta bien entrado septiembre, cuando, ya con las pilas recargadas, volveré al ataque con nuevos artículos y enlaces interesantes. Eso sí, durante este periodo seguiré echando el ojo periódicamente a comentarios o mensajes que me dejéis, aunque no los responderé con la misma celeridad que en otras épocas del año.
Aprovecho para desearos a todos un feliz verano y que disfrutéis de las vacaciones. ¡Nos vemos a la vuelta!
Publicado en Variable not found.
Publicado por José M. Aguilar a las 8:05 a. m.
Etiquetas: blogging, vacaciones
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- ¿Se pueden crear componentes Blazor que no hereden de ComponentBase o alguno de sus descendientes?
José María Aguilar - Consejos imprescindibles por si algo falla
José María Aguilar
.NET Core / .NET
- The minimal API AOT compilation template: Exploring the .NET 8 preview Part 1 & Part 2
Andrew Lock - TimeProvider and ITimer: Writing Unit Tests with Time in .NET 8 Preview 4
Artur Ampilogov - Roslyn Compiler and Analyzers in .NET
Code Maze - Why I like and prefer xUnit
Steven Giesel - Adding a Readme to NuGet Package Landing Pages
Khalid Abuhakmeh - Finding Symbols in Your C# Projects Using Roslyn
Calvin A. Allen - Converting a Byte Array to Hexadecimal String in C#
Code Maze - Customizing Return Value Behavior in Wolverine for Profit and Fun
Jeremy D. Miller - 7 Things about C#: If Statements
Joe Mayo - Discriminated Unions in C# With OneOf
Ryan Miranda - Improved Source Generators and Code Fixers Arrive in .NET Community Toolkit 8.2.1!
Sergio Pedri - Microsoft .NET Code Analysis: UTF-7 Encoding Is Insecure
David McCarter
Por decimotercer año consecutivo, me complace enormemente informaros de que Microsoft ha tenido a bien reconocerme de nuevo como MVP (Most Valuable Professional) en tecnologías de desarrollo. ¡13 años ya, uau! ¡Pero si el primero parece que fue ayer!
Muchas gracias al increíble equipo de Microsoft que hay detrás de este programa por haberme honrado con este reconocimiento, y especialmente a nuestra gran Cristina González por su dedicación, cercanía y ponérnoslo todo tan fácil cuando la necesitamos.
También agradeceros a vosotros, mis queridos amigos, que sois los que con vuestras visitas, lecturas, comentarios y apoyo incondicional hacéis que este sueño siga siendo posible año tras año.
¡Nos vemos por aquí!
Publicado en Variable not found.
Seguro que habéis visto más de una vez un código parecido al siguiente, en el que llamamos a una API REST externa y su resultado es deserializado a un objeto .NET para introducirlo en el flujo de la aplicación:
async Task<User[]> GetUsersAsync()
{
var httpClient = _httpClientFactory.CreateClient();
// Hacemos la llamada
var response = await httpClient.GetAsync("https://jsonplaceholder.typicode.com/users");
// Si la cosa no fue bien, retornamos
if (!response.IsSuccessStatusCode)
return Array.Empty<User>();
// Descargamos la respuesta y la deserializamos
var usersAsJson = await response.Content.ReadAsStringAsync();
var users = JsonSerializer.Deserialize<User[]>(usersAsJson);
return users;
}
Fijaos que el JSON de la respuesta de la API lo guardamos en una cadena de caracteres para, justo después, deserializarlo y convertirlo en un array de objetos User
. Que levante la mano el que no lo haya hecho nunca 😉
¿Y veis dónde está el problema? A la salida de este método, tendremos en memoria dos copias de los datos de los usuarios, una en forma de string
JSON y otra en el objeto que hemos deserializado.
Si estamos hablando de respuestas pequeñas o con poca concurrencia, probablemente el impacto es inapreciable. Pero si las estructuras retornadas por la API tuvieran un tamaño considerable o estamos en un escenario de múltiples llamadas simultáneas, esta duplicidad sería un auténtico derroche de recursos.
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)
Por si te lo perdiste...
- Expresiones new con el tipo de destino en C# 9
José María Aguilar - ¿Esa enumeración está vacía?
José María Aguilar
.NET Core / .NET
- El inyector de dependencias de .Net
Fernando Escolar - Consideraciones al publicar un paquete NuGet
Iván Montilla - Missing Stack trace when eliding the await keyword
Steven Giesel - Using the new configuration binder source generator: Exploring the .NET 8 preview
Andrew Lock - Log4net Appenders Introduction With C# Examples
Muhammed Saleem - How to Use Factory Pattern With Dependency Injection in .NET
Ahsan Ullah - 7 Things about C#: Console I/O
Joe Mayo - Microsoft .NET Code Analysis: Always Add Braces in C#
David McCarter - Test Data Generation With AutoFixture in .NET
Code Maze - Rx.NET v6.0: Enhancing Compatibility, Trimming Support, and Many More
Almir Vuk - LINQ: Select.Where or Where.Select?
Steven Giesel - Using Explicit Operators in Microsoft .NET to Perform Type Conversions
David McCarter - How to Hash Passwords with BCrypt in C#
Claudio Bernasconi - Introduction to .NET Releases And Updates
Aram Tchekrekjian - How to Generate C# Business Object Class from a CSV File
Greg Lutz
Cuando en ASP.NET Core MVC usamos rutado por convención, lo habitual es que accedamos a las acciones mediante rutas definidas en el patrón, como [controller]/[action]
. Así, podemos encontrarnos con rutas como /PendingInvoices/ViewAll
para acceder a la siguiente acción:
public class PendingInvoicesController : Controller
{
public IActionResult ViewAll() => Content("Show all pending invoices");
}
Lo mismo ocurre con páginas Razor. Si usamos las rutas por defecto, al archivo /Pages/ShowAllPendingInvoices.cshtml
podríamos acceder mediante la ruta /ShowAllPendingInvoices
. No es que sean rutas terribles, pero tampoco podemos decir que sean lo mejor del mundo en términos de legibilidad y conveniencia.
El kebab-casing consiste en separar con un guion "-" las distintas palabras que componen los fragmentos de la ruta, por lo que en los casos anteriores tendríamos /pending-invoices/view-all
y show-all-pending-invoices
, algo bastante más legible, elegante, y apropiado desde el punto de vista del SEO.
El nombre kebab-casing viene de que visualmente el resultado es similar a un pincho atravesando trozos de comida. Imaginación que no falte 😉
En este post vamos a ver cómo aprovechar los puntos de extensibilidad del sistema de routing de ASP.NET Core para modificar la forma en que genera rutas y así adaptarlo a nuestras necesidades.