Aplicación de prueba
Preámbulo
1. Una migración histórica
Antes de comenzar a explorar nuestra aplicación de prueba en este capítulo, vale la pena dar algunas explicaciones sobre ella.
La aplicación inicial era una solución compuesta de dos partes: un servicio web ASMX y una aplicación cliente WinForms. Aunque estas tecnologías siguen existiendo hoy en día, está claro que su uso conjunto ya no es un caso de uso generalizado (y si lo es, debe ser más de mantenimiento que de creación). Sin embargo, si le interesa más este caso que el actual, se le recomienda que compre la primera edición de este libro, que es más apropiada.
Sin embargo, el concepto de «cliente-servidor» aún persiste, aunque hoy se hable más de «front-end» y «back-end». Para ello, el servicio web de ASMX se ha migrado a ASP.NET WebApi y la aplicación WinForms a Blazor WebAssembly, todo ello utilizando .NET 6.
Hay que señalar que se ha hecho un esfuerzo especial para preservar en lo posible los problemas planteados por la primera versión, pero debido a los cambios en el uso y las tecnologías subyacentes se han añadido nuevos problemas, muy a menudo encontrados por el autor durante sus auditorías.
Además, los lectores que tengan suficiente experiencia con las últimas versiones de .NET probablemente se sentirán...
Criterios de elección
1. ¿Por qué esta aplicación?
Como ya se ha explicado en varias ocasiones, la filosofía de este libro no es explicar de forma experta todos los mecanismos internos de .NET ni analizar todas las optimizaciones finas de rendimiento posibles, sino mostrar las causas más comunes de la degradación del rendimiento en las aplicaciones .NET. Las causas son a veces sencillas, pero encontrar el punto de bloqueo preciso a partir de los síntomas encontrados es a menudo más complejo. La idea aquí no es hacer una puesta a punto, sino mostrar los casos típicos de programación incorrecta que conducen a un rendimiento degradado.
Dicho esto, se hizo evidente que la aplicación de demostración solo podía basarse en un software industrial real. Habiendo insistido tanto en abordar las causas reales, lejos del punto de vista académico, habría sido un error proponer la aplicación de métodos de perfilado en una aplicación de prueba desvinculada con la realidad.
Para ello, en el marco de esta segunda edición, se ha hecho un esfuerzo especial por mantener al máximo en la medida de lo posible los distintos objetos y rutinas empresariales que estaban presentes en la primera edición. No obstante, el cambio de tecnología ha hecho que se realicen algunas modificaciones, donde el autor ha introducido los errores de programación más comunes.
2. Utilizar la retroalimentación
Utilizar una aplicación real tiene también la ventaja de que no hay que imaginar casos problemáticos. Por experiencia, a veces...
Aplicación seleccionada
1. Campo de uso
La aplicación elegida, o más bien la plataforma elegida para las demostraciones, ya que es una plataforma común para varias aplicaciones, está basada en .NET 6. La primera aplicación que utiliza esta plataforma es una aplicación de gestión muy tradicional, que utiliza fichas y un sistema de flujo de información, todo ello complementado con módulos para la elaboración de informes, procesamiento masivo, etc. La segunda aplicación utiliza el mismo sistema para proporcionar al usuario motores de modelización para cálculos presupuestarios más complejos.
2. Arquitectura
De forma global, la plataforma permite crear aplicaciones que consisten en un cliente Blazor WebAssembly que se comunica con una ASP.NET WebAPI que contiene la lógica del negocio, que a su vez se comunica con las bases de datos a través de un mecanismo multibase utilizando directamente ADO.NET. Se trata de una mutación de la arquitectura inicial, que se transformará a medida que avancemos hacia los estándares de código modernos.
3. Interfaz
El objetivo del libro es mostrar estructuras de código y arquitectura de soluciones de bajo rendimiento. Por lo tanto, estaba fuera de lugar abarrotar el código con la más mínima línea relacionada con la estética o incluso la ergonomía....
Detalles de la aplicación
1. Encontrar la aplicación
El autor recomienda que, para entender lo que sigue, se tome unos minutos para familiarizarse con la aplicación de prueba. Esta aplicación, llamada PROFI, puede descargarse del sitio web de Ediciones ENI (tenga cuidado y elija la versión de la carpeta AntesOptimizacion y no la de la carpeta DespuesOptimizacion.
A riesgo de repetirse, la aplicación objetivo es una especie de antipatrón global de código de rendimiento. Un ojo entrenado pronto se dará cuenta de que está codificada de forma catastrófica. Ese es el objetivo: esta aplicación debe retomar todos los problemas de rendimiento y añadir todos los demás casos estándar que el autor quiera mostrar a través del perfilado. Por lo tanto, se invita al lector a contener su posible indignación mientras estudia su código y funcionamiento, ya que es natural que PROFI refleje todas las malas prácticas de codificación.
2. Instalar la base de datos
Con el objetivo de simplificar el trabajo de instalación de la base de datos, el autor propone varios enfoques, entre los que el lector puede elegir el que le parezca más fácil de aplicar. Para que la aplicación no esté limitada por el rendimiento del SGBD (Sistema Gestor de Bases de Datos), se ha elegido SQL Server como base de datos. Hay que tener en cuenta que SQL Server se puede ejecutar libremente en cualquier ordenador que pueda ejecutar Docker.
Para ello, proceda así:
-
Instale Docker en su sistema.
-
Ejecute un contenedor que contenga la imagen ejecutando el siguiente comando:
docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=10mdpAdmin !" -p
1433 :1433 -d mcr.microsoft.com/mssql/server :2019-latest
Una vez realizados estos dos pasos, obtendrá un contenedor que ejecuta SQL Server y será accesible localmente a través del puerto 1433.
Si el lector ya ha instalado Visual Studio 2022 en Windows, una instancia de desarrollo de SQL Server, llamada LocalDb, queda automáticamente disponible.
Todos los archivos mencionados a continuación están disponibles en los archivos que se entregan con el libro y que pueden descargarse del sitio web de Ediciones ENI o del repositorio GitHub en el directorio de instalación.
a. Crear manualmente
La primera posibilidad...
Explicación sobre la complejidad de la aplicación
Quizá el lector se haya dado cuenta de que, para una simple aplicación de demostración, exista una división en numerosos proyectos, la arquitectura del cliente que separa los controles de Blazor, etc. son muy aparatosos. Esto está muy lejos de las buenas prácticas Agile de simplicidad de los desarrollos.
Es cierto que, en teoría, si solo hubiéramos querido crear una aplicación para satisfacer las pocas necesidades empresariales expuestas en PROFI, habría sido posible crear simplemente un ejecutable con todo el código codificado en duro y una API que contuviera la lógica del negocio y el acceso a la base de datos. Otra posibilidad habría sido hacer todo en Blazor Server, con Blazor Server funcionando en el servidor dándonos la posibilidad de acceder a la base de datos directamente. Si la aplicación realmente solo iba a mostrar personas y contratos, los métodos Agile recomiendan producir el código más sencillo posible y, evidentemente, el código presente sería una enorme sobrearquitectura.
Pero hay una buena razón detrás de este aparente sobrepeso del código de la aplicación: PROFI se inspira en una aplicación real, de modo que muestra problemas de rendimiento realistas cuando se aplica a un proyecto más allá del marco...
Método recomendado
A medida que vayamos leyendo los próximos capítulos, donde iremos desgranando los distintos puntos conflictivos de rendimiento de esta aplicación objetivo, será importante tener en cuenta algunos principios de trabajo, además de los principios básicos del perfilado expuestos en la introducción.
El primer principio es no confiar nunca en su instinto de desarrollador en lo que concierne al rendimiento. Se demostrará ampliamente que lo que creemos que es un cuello de botella a menudo no causa ningún problema, y que lo que debería impulsar la reducción del rendimiento es una confianza ciega en las herramientas que nos permiten comprobarlo.
El segundo principio para implementar soluciones es pensar siempre en términos de simplicidad. Los problemas de rendimiento en una aplicación provienen del hecho de que, para realizar una operación de «negocio», el ordenador tiene que realizar más operaciones «atómicas» de las realmente necesarias. Es importante distinguir siempre entre la complejidad algorítmica y la complejidad real del problema. La primera no debe ser más alta que la segunda. El reflejo de reajustar un problema de rendimiento puede ser de doble filo.
Si pensamos en términos de refactorización, es decir, en mantener el mismo comportamiento simplificando las operaciones internas...