Las top level statements o instrucciones de nivel superior de C# 9 introdujeron una alternativa muy concisa para implementar los entry points de nuestras aplicaciones. De hecho, en .NET 6 fueron introducidas como la opción por defecto en las plantillas, por lo que, de alguna forma, se nos estaba forzando a utilizarlas en todos los nuevos proyectos.
Y como casi siempre sucede, rápidamente aparecieron numerosos desarrolladores a los que este cambio no les había hecho nada de gracia, y se manifestaron claramente en contra de que esta fuera la opción por defecto. La decisión por parte de los equipos de Visual Studio y .NET, que ya podemos ver si tenemos las últimas actualizaciones instaladas, es dejar que cada desarrollador decida la opción que más le guste.
Publicado por José M. Aguilar a las 8:05 a. m.
Etiquetas: aspnetcore, netcore, trucos, vs2022
Versiones de .NET anteriores a la 6 no disponían de una fórmula específica para determinar si un tipo o interfaz está registrado como servicio en el sistema de inyección de dependencias.
La única forma de hacerlo era intentar resolverlo, usando métodos como GetService()
o GetService<T>()
, y comprobar si el resultado era null
:
var myService = serviceProvider.GetService<IMyService>();
if(myService is null)
{
// El servicio no está registrado, hacemos algo
}
¿Cuál es el inconveniente de esto? Si el servicio no está registrado, ninguno: la llamada retornará un nulo y listo.
El problema viene cuando sí está registrado, pues estaremos forzando la resolución de un servicio que, en realidad, no necesitamos para nada, pues sólo nos interesaba saber si existía o no. Porque recordemos que la resolución de un servicio podría tener un coste importante en términos de rendimiento, memoria, o incluso efectos colaterales en el estado de la aplicación, especialmente si nuestro servicio depende de otros, que a su vez dependen de otros, etc.
No hace demasiado tiempo he descubierto en el framework la clase ActivatorUtilities
, una pequeña joyita disponible en Microsoft.Extensions.DependencyInjection
, que puede resultar interesante para implementar fácilmente factorías o cualquier tipo de código donde tengamos que instanciar manualmente clases con dependencias hacia servicios registrados en el contenedor de nuestra aplicación.
La clase estática ActivatorUtilities
ofrece básicamente tres métodos públicos:
CreateFactory()
, para crear factorías de objetos.CreateInstance()
/CreateInstance<T>()
, para crear instancias de objetos.GetServiceOrCreateInstance()
/GetServiceOrCreateInstance<T>()
, para obtener una instancia desde el inyector, o bien crearla manualmente conCreateInstance()
.
Hoy voy a hablar de un cambio introducido en el framework hace ya algunos años, que, al menos en mi caso, pasó totalmente desapercibido en su momento y durante bastante tiempo después. Y he pensado que sería buena idea publicar sobre ello porque, como este mundo es así de grande, seguro que hay todavía algún despistado al que podría estar afectando a día de hoy y ni siquiera se ha dado cuenta :)
Como recordaréis, los atributos de validación [EmailAddress]
y [Url]
, presentes en el espacio de nombres System.ComponentModel.DataAnnotations
, los hemos utilizado durante años para asegurar que determinados valores de entrada eran direcciones de correo electrónico y URLs válidas, respectivamente:
public class Blog
{
[Required, EmailAddress]
public string ContactEmail { get; set; }
[Required, Url]
public string Url { get; set; }
}
Desde el principio de los tiempos, aún en ASP.NET "clásico", ambos atributos de validación utilizaban internamente complejas expresiones regulares para comprobar los valores, y la verdad es que funcionaban relativamente bien. Nuestras aplicaciones podían confiar en que valores que hubieran superado dichas validaciones serían, como mínimo, sintácticamente correctos y buenos candidatos a ser direcciones de correo o URLs válidas.
Pues bien, desde la llegada de NET 4.7.2, y luego en .NET Core, [EmailAddress]
y [Url]
ya no funcionan así. En palabras casi textuales del equipo de desarrollo, el objeto de estos dos atributos es simplemente prevenir algunos errores básicos al teclear, y no contemplar todas las posibilidades definidas en las respectivas RFC que describen la sintaxis de dichos valores.
El estado actual de acumulación de SDKs podéis conocerlo muy fácilmente desde línea de comandos utilizando la orden
dotnet --list-sdks
:C:\>dotnet --list-sdks
1.1.11 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.503 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.1.505 [C:\Program Files\dotnet\sdk]
2.1.507 [C:\Program Files\dotnet\sdk]
2.1.508 [C:\Program Files\dotnet\sdk]
2.1.509 [C:\Program Files\dotnet\sdk]
2.1.511 [C:\Program Files\dotnet\sdk]
2.1.602 [C:\Program Files\dotnet\sdk]
2.1.604 [C:\Program Files\dotnet\sdk]
2.1.700 [C:\Program Files\dotnet\sdk]
2.1.701 [C:\Program Files\dotnet\sdk]
2.1.800-preview-009696 [C:\Program Files\dotnet\sdk]
2.1.801 [C:\Program Files\dotnet\sdk]
2.1.802 [C:\Program Files\dotnet\sdk]
2.2.102 [C:\Program Files\dotnet\sdk]
2.2.105 [C:\Program Files\dotnet\sdk]
2.2.202 [C:\Program Files\dotnet\sdk]
2.2.203 [C:\Program Files\dotnet\sdk]
2.2.204 [C:\Program Files\dotnet\sdk]
3.0.100-preview8-013656 [C:\Program Files\dotnet\sdk]
3.0.100-preview9-014004 [C:\Program Files\dotnet\sdk]
3.0.100 [C:\Program Files\dotnet\sdk]
3.1.100 [C:\Program Files\dotnet\sdk]
3.1.101 [C:\Program Files\dotnet\sdk]
3.1.102 [C:\Program Files\dotnet\sdk]
C:\>_
En mi caso, tengo aún por ahí el SDK de .NET Core 1.x, un par de decenas de .NET Core 2.x, y algunas previews, pero los he visto mucho peores ;) Obviamente, salvo dos o tres versiones que quizás me interesen porque tengo aplicaciones que aún no he migrado, el resto ocupan en mi equipo un espacio considerable sin motivo, más de 5GB, pues cada SDK puede pesar entre 150 y 200 Mb.
try/catch
porque el mero hecho de usar este tipo de bloque de código afectaba al rendimiento.
La verdad es que de forma intuitiva se puede adivinar que esto no debería ser así. Si no se producen excepciones en un código que tengamos envuelto en un
try/catch
se debería ejecutar virtualmente a la misma velocidad que si no usáramos este tipo de bloque. Cosa distinta es si producen excepciones: ahí el rendimiento sí se verá seriamente penalizado, pero no es culpa del try/catch
sino del propio sistema de gestión de excepciones de .NET.Pero claro, lo dicho anteriormente es sólo cierto si somos capaces de demostrarlo, así que usaremos nuestro viejo conocido
BenchmarkDotnet
para desmontar este mito.Personalmente me gusta tener todos los entornos y herramientas de desarrollo en inglés, básicamente porque cuando encontramos problemas es más fácil encontrar soluciones si a la hora de buscar utilizamos los términos en este idioma... bueno, y de paso, evito ver algunas traducciones terribles ;)
Pues bien, en el caso del SDK de .NET Core, el idioma no es una característica que podamos elegir a la hora de instalarlo. Se instalarán todos los idiomas disponibles (podéis verlo por ejemplo en la carpeta
%programfiles%\dotnet\sdk\3.1.101
), y los mensajes se mostrarán en el idioma configurado por defecto en nuestra máquina. En mi equipo, por ejemplo, se muestra todo en idioma español:C:\>dotnet xyz
No se pudo ejecutar porque no se encontró el comando o archivo especificados.
Algunas de las posibles causas son:
* Escribió mal un comando dotnet integrado.
* Intentó ejecutar un programa .NET Core, pero dotnet-xyz no existe.
* Tiene planeado ejecutar una herramienta global, pero no se encontró un ejecutable
con prefijo dotnet con este nombre en la RUTA DE ACCESO.
C:\>_
El hecho de que en el equipo destino esté preinstalado el runtime es muy interesante, entre otras cosas porque permite asegurar de antemano que en él se encontrarán todas las dependencias (frameworks, bibliotecas, paquetes, metapaquetes) necesarios para una correcta ejecución. Por tanto, para distribuir nuestra aplicación sólo debemos generar lo relativo a nuestro código, el resto ya estará allí.
Esta forma de publicar aplicaciones se denomina framework-dependent, pues dependen de que determinados componentes del framework estén instalado en el destino.Por ejemplo, el paquete de publicación de una aplicación de consola prácticamente vacía, que únicamente muestra el mensaje "Hello world!", ocuparía solo 175K:
D:\MyConsoleApp\output>dir
El volumen de la unidad D es Datos
El número de serie del volumen es: 8CBC-81E3
Directorio de D:\MyConsoleApp\output
09/02/2020 18:47 <DIR> .
09/02/2020 18:47 <DIR> ..
09/02/2020 18:46 428 MyConsoleApp.deps.json
09/02/2020 18:46 4.608 MyConsoleApp.dll
09/02/2020 18:46 169.984 MyConsoleApp.exe
09/02/2020 18:46 668 MyConsoleApp.pdb
09/02/2020 18:46 154 MyConsoleApp.runtimeconfig.json
5 archivos 175.842 bytes
2 dirs 463.058.874.368 bytes libres
D:\MyConsoleApp\output>_
Otra ventaja de este tipo de distribución es que es cross platform pura, es decir, podemos copiar los archivos a cualquiera de los sistemas operativos soportados y, siempre que dispongan del runtime, nuestra aplicación podrá correr sobre ellos sin problema.Y todo esto está muy bien, pero, ¿qué pasa si quiero crear una aplicación portable, de forma que pueda distribuirla y ejecutarla sin necesidad de que el equipo destino tenga nada preinstalado?
Pues eso es lo que veremos en este post ;)
Pues bien, esto ha cambiado a partir de la versión 3.0, en mi opinión, hacia una dirección bastante más correcta. Veamos en qué consisten estos cambios.
En este post echaremos un vistazo a gRPC y su uso en la nueva versión del framework.
Esta capacidad abre posibilidades bastante interesantes,que no eran tan inmediatas (o en algunos casos, ni siquiera posibles de forma directa) en versiones "clásicas" de Entity Framework, o EF Core anterior a 2.1. Gracias a ella podremos, por ejemplo, tener en nuestra entidad una propiedad de tipo enum mapeada a una cadena de caracteres en el almacén de datos, o introducir cualquier lógica de transformación, como podría ser la desencriptación y encriptación de valores, a la hora de leer y persistir información.
En versiones anteriores a EF Core 2.1 y todos sus antecesores "clásicos", un problema que era difícilmente salvable era la necesidad de que en las entidades existiera un constructor público sin parámetros.
Esto tenía sentido, pues debíamos proporcionar al framework una vía para crear las instancias al materializarlas desde el almacén de datos. De hecho, al materializar, el marco de trabajo usaba dicho constructor para crear la instancia, y luego iba poblando las propiedades una a una utilizando sus setters (o estableciendo el valor de sus backing fields, como vimos en un post anterior)
Ya llevamos varios posts dedicados a comentar algunas características novedosas o que cambian bastante respecto a las versiones anteriores (como la evaluación en cliente o las shadow properties, y vamos a continuar en esta línea presentando ahora otra interesante novedad: el soporte para campos de respaldo o backing fields.
Por ejemplo, si instalamos en nuestro equipo la preview del SDK 3.0, a partir de ese momento todos los comandos de la CLI se ejecutarán utilizando esta versión preliminar, como cuando creamos un nuevo proyecto usando
dotnet new
; en este caso, el proyecto se construirá usando la plantilla proporcionada por la versión más actual del framework (aunque sea preview), lo cual puede resultar molesto en algunas ocasiones.En este post vamos a ver cómo el propio SDK dispone de mecanismos que nos permiten seleccionar una versión específica, para lo cual trataremos varios comandos útiles de la CLI.
using
... pinta divertido, sin duda :DEn el futuro iremos comentando las características más interesantes, pero, de momento, este post vamos a dedicarlo exclusivamente a ver cómo podemos comenzar a probar C# 8 desde nuestro flamante Visual Studio 2019 u otros entornos, como VS Code o incluso la CLI.
Si aún no habéis tenido el ratillo para instalar la última versión de Visual Studio, ya estáis tardando ;DEl único problema es que necesitamos compiladores que entiendan la sintaxis de C# 8, y de momento esto sólo es posible usando la preview de .NET Core 3. Pero vaya, nada que no podamos solucionar en un par de minutos; veamos cómo.
En concreto, la duda le surgía al combinar las capacidades de data seeding de EF con las propiedades ocultas, y básicamente era:
Dado que las shadow properties no existen en la entidad, ¿cómo podemos establecerlas en el momento del seeding de datos?Bien, aunque no es fácil de descubrir de forma intuitiva, la solución es bastante sencilla. Si nos fijamos en el intellisense del método que utilizamos para el poblado de datos,
HasData()
, podemos observar varias sobrecargas; por ejemplo, en la siguiente captura se puede ver la información mostrada al invocar este método para la entidad Friend
:A grandes rasgos, se trata de la capacidad de este framework para gestionar propiedades de una entidad que existen en el almacén datos pero no en la clase .NET que la representa en el mundo de los objetos.
De forma intuitiva podemos saber que esto ya existía en las versiones clásicas de Entity Framework. Por ejemplo, cuando introducíamos una propiedad de navegación entre dos entidades sin usar una clave foránea de forma explícita, el propio marco de trabajo creaba, por convención, una columna en la base de datos para almacenar dicha referencia, como en el siguiente escenario:
public class Friend
{
public int Id { get; set; }
public string Name { get; set; }
// Se crea una columna CountryId en la base de datos,
public Country Country { get; set; } // pero no existe en la entidad.
}
El valor de dicha columna CountryId
no podía ser manipulada de forma directa porque se trataba de información usada internamente para gestionar las relaciones y su valor era obtenido y actualizado de forma transparente para nosotros.Pues bien, Entity Framework Core aporta la capacidad para gestionar este tipo de campos "ocultos" para servir a nuestros propios intereses. De esta forma, podríamos añadir a una entidad propiedades que no tienen por qué estar visibles en la clase .NET en forma de propiedades; un ejemplo podría ser el clásico "IsDeleted" cuando implementamos borrado lógico, o información de auditoría como los tradicionales "UpdatedAt" o "UpdatedBy".
Sin embargo, estas ayudas tienen un coste importante, al igual que ocurre con casi cualquier framework al que vayamos a confiar parte de nuestro sistema, sea del ámbito que sea: hay que conocerlo bien para no dispararse en un pie en cuanto apretemos el gatillo.
Hace muuuuchos, muchos años hablamos de cómo aplicar convenientemente la carga anticipada (eager loading) en Entity Framework podía acelerar de forma drástica el rendimiento en el acceso a datos de nuestras aplicaciones, evitando el temido problema denominado "SELECT N+1". Esto continúa siendo válido para la versión Core de este marco de trabajo: sigue existiendo el extensor
Include()
e incluso variantes de éste como ThenInclude()
que permiten incluir en una única consulta las entidades que sabemos que vamos a necesitar.Pues bien, en EF Core hay otro detalle que, si bien utilizándolo con conocimiento puede resultar muy interesante, es fácil que nos tumbe el rendimiento de nuestros accesos a datos si no lo usamos con cuidado: la evaluación en cliente.
Blogger invitado
Jorge Turrado
Apasionado de la programación, siempre buscando la manera de mejorar el día a día con el desarrollo de tecnologías .NET. Apasionado de este momento tan cambiante y fabuloso para ser desarrollador C#.¿Y por qué me debería interesar utilizar código nativo si .NET Core ya es lo bastante rápido? Esa es una muy buena pregunta, es cierto que con .NET Core y su filosofía cloud se ha mejorado muchísimo el rendimiento, y se ha modularizado el framework consiguiendo unos resultados muy buenos.
Sin embargo, imagina que tu aplicación web necesita de un rendimiento excelente, por ejemplo, porque necesites enviarle imágenes y tengas que procesarlas en el servidor para leer un OCR o procesar su contenido. En estos casos, cada ciclo cuenta, ya que afecta directamente a la escalabilidad de tu aplicación; no es lo mismo tardar 10 milisegundos que 20, cuando hablas de un gran número de usuarios concurrentes.
El framework nos da la posibilidad de ejecutar código nativo (ya .NET Framework nos daba esa posibilidad hace mucho), pero el código nativo es código compilado directamente para el sistema operativo, y esto hace que una librería de Windows sólo sirva para Windows, lo mismo que si fuese de Linux o MacOS.
Hoy vamos a abordar ese problema, creando librerías nativas multiplataforma, que podamos compilar sin tener que cambiar nada en ellas (lo cual nos permite tener una única librería que mantener) y consumiéndolas desde .NET Core. Por eso, en mi blog FixedBuffer he dejado la primera parte de esta entrada:
Crear y utilizar librerías multiplataforma con C++ y .NET Core (Parte 1)
A partir de aquí, vamos a considerar que ya tenéis vuestra librería nativa compilada, y vamos a centrarnos solo en la parte de C# y .NET Core.
Publicado por José M. Aguilar a las 10:00 a. m.
Etiquetas: c++, colaboraciones, jorgeturrado, netcore
Hoy en día, salvo en contadas ocasiones, ha dejado de tener sentido invertir demasiado tiempo en estas labores. Tenemos máquinas potentes, con micros cuya velocidad se mide en GHz capaces de ejecutar bastantes tareas de forma concurrente, y muchos Gigabytes libres de memoria RAM en los que guardar información. Además, los frameworks actuales como .NET permiten despreocuparse de asuntos como la reserva o liberación de memoria porque ya hay sistemas de más bajo nivel que se encargan de eso por nosotros.
Indudablemente es un gran avance, pero esto ha llevado a que, con el tiempo, se nos esté atrofiando ese sentido arácnido que antes nos disparaba las alertas cuando cierto código podía ser optimizado para consumir menos recursos.
En la mayoría de escenarios, y sobre todo cuando trabajamos en entornos empresariales, aplicaciones de escritorio o webs de poca carga, está bien así. Sin embargo, es cierto también que las necesidades han cambiado.
Por ejemplo, ahora creamos frecuentemente aplicaciones mucho más complejas que pueden ser utilizadas a través de Internet por miles de usuarios de forma simultánea y todos ellos esperan respuestas rápidas. Estas aplicaciones se ejecutan en servidores cuyos recursos son compartidos entre todos los usuarios que pueden llegar a tener un coste importante y debemos exprimir al máximo. Aquí, y en otros escenarios similares, es donde aparece de nuevo la necesidad de introducir optimizaciones en el código.
En este post vamos a hacer una introducción al uso de BenchmarkDotNet, una magnífica herramienta que nos permitirá medir el rendimiento de nuestro código .NET para hacerlo más eficiente en términos de uso de procesador y memoria.
Pero antes de empezar, no olvidéis la famosa frase de Donald Knuth:
“Los programadores consumen una gran cantidad de tiempo pensando, o preocupándose, sobre la velocidad de partes no críticas de sus programas, y esos intentos de mejorar la eficiencia tienen posteriormente un gran impacto negativo sobre la facilidad de depuración o mantenimiento. Deberíamos olvidarnos de las pequeñas mejoras de eficiencia, digamos en un 97% de los casos: la optimización prematura es el origen de todos los males. Sin embargo, no debemos dejar pasar la oportunidad de mejorar ese crítico 3% restante”
Publicado por José M. Aguilar a las 8:30 a. m.
Etiquetas: netcore, netframework, rendimiento, trucos