> For the complete documentation index, see [llms.txt](https://elguerre.gitbook.io/de0an/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elguerre.gitbook.io/de0an/capitulo-11-backstage-y-un-futuro-prometedor/cimientos-modernos.md).

# Cimientos Modernos

El capítulo 4 fue donde sentamos las bases de nuestra aplicación. Elegimos MVVM como patrón arquitectónico, configuramos Template 10 como framework de partida, integramos NuGet para la gestión de dependencias y conectamos todo con VSTS (hoy Azure DevOps) para el control de versiones.

Fueron decisiones fundamentales que condicionaron todo lo que vino después. Y eso no ha cambiado: los cimientos siguen siendo lo más importante de cualquier proyecto.

## De MVVM a componentes con Signals

MVVM (Model-View-ViewModel) fue una elección natural para UWP y XAML. El data binding bidireccional, los commands y la separación entre vista y lógica nos permitieron construir una aplicación mantenible y testeable.

En Angular, el concepto evoluciona hacia un modelo basado en **componentes** con **Signals**:

| MVVM (UWP)             | Angular moderno                  |
| ---------------------- | -------------------------------- |
| View (XAML)            | Component Template (HTML)        |
| ViewModel              | Component Class (TypeScript)     |
| Model                  | Interfaces / Services            |
| Data Binding           | Signals + Template Syntax        |
| ICommand               | Event handlers + Output signals  |
| INotifyPropertyChanged | Signals (reactividad granular)   |
| ViewModelLocator       | Inyección de dependencias nativa |

Los **Signals** de Angular merecen especial atención. Introducidos a partir de Angular 17, representan un cambio fundamental en la forma de gestionar el estado reactivo:

```typescript
// Antes: Observable con RxJS
private _tareas$ = new BehaviorSubject<Tarea[]>([]);
tareas$ = this._tareas$.asObservable();

// Ahora: Signal (más simple, más eficiente)
tareas = signal<Tarea[]>([]);
tareasCompletadas = computed(() =>
  this.tareas().filter(t => t.completada)
);
```

Si vienes de XAML y su data binding, los Signals te resultarán familiares: defines un valor reactivo, y todo lo que depende de él se actualiza automáticamente. Sin suscripciones manuales, sin fugas de memoria.

## .NET Aspire: orquestación moderna

En el capítulo 4, configurar la infraestructura del proyecto (base de datos, servicios, configuración) era un proceso manual. Hoy, **.NET Aspire** cambia las reglas del juego.

Aspire es un framework de orquestación para aplicaciones distribuidas en .NET. Con él puedes:

* **Definir tu infraestructura como código**: base de datos, cache, mensajería, todo declarado en C#.
* **Orquestar servicios**: arrancar frontend, backend, bases de datos y servicios auxiliares con un solo comando.
* **Observabilidad integrada**: OpenTelemetry configurado desde el primer momento.
* **Dashboard local**: un panel de control que muestra logs, trazas y métricas de todos tus servicios.

```csharp
var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("db")
    .AddDatabase("taskin");

var redis = builder.AddRedis("cache");

var api = builder.AddProject<Projects.TaskIN_Api>("api")
    .WithReference(postgres)
    .WithReference(redis);

builder.AddNpmApp("frontend", "../frontend")
    .WithReference(api)
    .WithHttpEndpoint(env: "PORT");

builder.Build().Run();
```

Con estas pocas líneas, Aspire configura y conecta PostgreSQL, Redis, la API .NET y el frontend Angular. Compara esto con la configuración manual que describimos en los capítulos 4 y 7.

## Gestión de dependencias

NuGet sigue siendo el gestor de paquetes para .NET, pero ahora se complementa con:

* **npm** para las dependencias del frontend Angular.
* **Angular CLI** (`ng add`) para añadir funcionalidades con un solo comando.
* **Dependabot** o **Renovate** para mantener las dependencias actualizadas automáticamente.

## CI/CD desde el día 1

En el capítulo 4 integramos VSTS al final, casi como un paso adicional. Hoy, la recomendación es clara: **configura CI/CD desde el primer commit**.

Con GitHub Actions, un archivo YAML en tu repositorio es suficiente para tener un pipeline que compile, testee y valide cada cambio. No hay excusa para dejar esto para después.

## La lección que permanece

Los cimientos determinan la altura que puede alcanzar el edificio. Elegir bien la arquitectura, los patrones y las herramientas al principio del proyecto sigue siendo la decisión más importante. La IA puede ayudarte a implementar esas decisiones más rápido, pero la decisión en sí — qué patrón usar, cómo organizar el código, qué tradeoffs aceptar — sigue siendo tuya.