Construí un sistema de cotizaciones real con .NET 10 y Blazor Server — y esto fue lo que aprendí

Cristóbal — Tue, 04 Aug 2026 23:30:37 +0000

Hace unas semanas empecé un proyecto personal con un objetivo simple: automatizar el proceso de cotización de una vidriería que hasta entonces armaba cada presupuesto a mano. Cálculos repetidos, formato distinto cada vez, cero historial ordenado.

Terminó siendo bastante más de lo que imaginé al principio: un sistema completo de gestión de presupuestos, con catálogo de productos, múltiples precios por proveedor, cálculo de márgenes, exportación a PDF con el formato real que ya usaba el negocio, y deployment como servicio en red local.

Stack:

.NET 10 + Blazor Server — interactividad renderizada en servidor, sin necesidad de una API separada
Entity Framework Core + SQLite
MudBlazor para la interfaz
QuestPDF para la generación del documento final

No fue un tutorial seguido al pie de la letra. Fue ir resolviendo, un problema real a la vez. Estos son tres momentos que me parecieron interesantes de compartir.

Pensar bien las reglas de borrado, no solo el modelo

Cuando modelás relaciones en Entity Framework Core, es fácil enfocarse solo en qué campo referencia a qué otro, y dejar OnDelete en su comportamiento por defecto. Pero cada relación tiene una pregunta de negocio detrás: ¿qué tiene que pasar si borro esto?

En este proyecto, un Cliente con presupuestos asociados no puede borrarse — hay que evitar perder historial comercial por accidente. En cambio, un ItemPresupuesto no tiene sentido de existir sin su Presupuesto padre, así que si el presupuesto se borra, sus ítems se van con él.

Bloque 1 — Relaciones y reglas de borrado (VidrieriaContext.cs)

csharp
entity.HasOne(p => p.Cliente)
.WithMany(c => c.Presupuestos)
.HasForeignKey(p => p.ClienteId)
.OnDelete(DeleteBehavior.Restrict);

entity.HasOne(p => p.Cotizador)
.WithMany()
.HasForeignKey(p => p.CotizadorId)
.OnDelete(DeleteBehavior.Restrict);
csharp
entity.HasOne(i => i.Presupuesto)
.WithMany(p => p.Items)
.HasForeignKey(i => i.PresupuestoId)
.OnDelete(DeleteBehavior.Cascade);

Misma herramienta (OnDelete), dos decisiones opuestas — y ambas correctas, según qué representa cada relación en el negocio.

Un selector de catálogo que escala sin volverse ilegible

El sistema tiene categorías con subcategorías, productos dentro de cada una, y cada producto con varios precios de referencia según el proveedor. Con pocos datos cargados, un árbol simple funciona bien — pero apenas crece el catálogo, navegar a fuerza de clicks se vuelve tedioso y aumenta el riesgo de elegir el ítem equivocado.

La solución fue un componente con búsqueda que filtra el árbol completo en memoria y auto-expande las ramas que coinciden:

Bloque 2 — Filtrado recursivo (SelectorProductoCatalogo.razor)

csharp
private bool CategoriaVisible(Categoria categoria) =>
!HayBusqueda
|| CategoriaNombreCoincide(categoria)
|| productosPorCategoria[categoria.Id].Any(ProductoCoincide)
|| categoriasPorPadre[categoria.Id].Any(CategoriaVisible);

Una categoría es visible si su nombre coincide, si tiene algún producto que coincide, o si alguna de sus subcategorías es visible (recursivamente). Con eso alcanza para que, al escribir en el buscador, el árbol se reduzca solo a las ramas relevantes — sin tocar la base de datos en cada tecla, todo resuelto sobre datos ya cargados en memoria con ILookup.

El bug que no tiraba ningún error

Este fue el más difícil de diagnosticar. Un botón dejó de responder — sin excepciones, sin nada en la consola del navegador, sin nada en el servidor. El circuito de Blazor estaba vivo, otros botones funcionaban.

La causa: unos componentes globales (proveedores de notificaciones y diálogos) vivían en el layout raíz de la aplicación, fuera del árbol de cualquier página con render mode interactivo. Quedaban renderizados una sola vez, en modo estático, y nunca se conectaban al circuito real.

Bloque 3 — El fix del render mode que dejaba botones "muertos"

razor

La lección que me llevo: en Blazor Web App, el render mode no se hereda entre componentes "hermanos" en el árbol — solo se propaga hacia los descendientes de quien lo declara. Un detalle chico, pero que sin entenderlo puede hacer perder horas.

Cierre

Ninguno de estos problemas apareció en un tutorial. Aparecieron usando el sistema de verdad, con datos reales, con un usuario real dándome feedback. Esa fue la parte más valiosa del proyecto: no solo escribir código que funcione, sino entender por qué algo no funcionaba antes de corregirlo.

Si te interesa la arquitectura, algún detalle técnico puntual, o simplemente charlar sobre el proyecto, los comentarios están abiertos. 👇

DEV Community: Cristóbal

Construí un sistema de cotizaciones real con .NET 10 y Blazor Server — y esto fue lo que aprendí