Como ya conté en un artículo anterior, .NET 6 no incluye fichero Startup.cs para apoyar los procesos de inicialización de una solución, sino que se implementa todo desde el propio Program.cs. Esto resulta beneficioso en proyectos simples pero, cuando aumentamos la complejidad, es posible que ese Program.cs comience a tener una cantidad de líneas poco manejable y se convierta en un fichero de «código espagueti» ¿Qué soluciones tenemos para crear un fichero Startup.cs en .NET 6?
Es la opción que se nos puede ocurrir de forma más inmediata y tampoco llega a ser mala. De esta forma, sólo necesitaremos crear un fichero, que podremos llamar como queramos pero que por consistencia deberíamos llamar Startup.cs, y donde vamos a crear los métodos que esperaríamos tener que serán llamados desde Program.cs. De esta forma mejoraríamos la legibilidad del código y, por tanto, la mantenibilidad.
public class Startup
{
public IConfiguration Configuration { get; }
public Startup(IConfiguration configuration)
{
this.Configuration = configuration;
}
public void ConfigureServices(IServiceCollection services)
{
// ...
}
public void Configure(IApplicationBuilder app, IHostApplicationLifetime lifetime)
{
// ...
}
}
El código, en un Program.cs por defecto, podría quedar de la siguiente forma.
var builder = WebApplication.CreateBuilder(args);
// CREATE STARTUP INSTANCE
var startup = new Startup(builder.Configuration);
// CONFIGURE SERVICES
startup.ConfigureServices(builder.Services);
// Add services to the container.
builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
var app = builder.Build();
/* CONFIGURE LIFETIME */startup.Configure(app, app.Lifetime);
Esta solución, aunque no aporta demasiados cambios, sí queresulta algo más elegante que la anterior que es… más de andar por casa. Para ello, lo que podemos hacer es usar métodos de extensión que nos permitan trabajar con los «antiguos» métodos de nuestro Startup.cs directamente conectados a los objetos «builder» y «app». Es importante que tengamos en cuenta que tanto la clase Startup (o como la queramos llamar) como los métodos de extensión, deben ser estáticos y declarar el objeto que queremos extender.
public static class Startup
{
public static void ConfigureServices(this WebApplicationBuilder builder)
{
// ...
builder.Services.AddMicrosoftIdentityWebApiAuthentication(builder.Configuration, "AzureAd");
builder.Services.AddControllers();
}
public static void Configure(this WebApplication app)
{
// ...
app.UseCors();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
}
var builder = WebApplication.CreateBuilder(args); // Add services to the container. // CONFIGURE SERVICES builder.ConfigureServices(); builder.Services.AddControllers(); // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); var app = builder.Build(); // CONFIGURE APP IN YOUR STARTUP app.Configure(); app.Run();
Como se puede ver, la solución es más elegante que simplemente crear una clase e instanciarla o hacerlo creando métodos estáticos.
Aunque ya no disponemos del fichero Startup.cs como en versiones anteriores de .NET Core, sí que podemos buscar alternativas en .NET 6 que nos separar el código en ficheros y así evitar convertir Program.cs en código espagueti imposible de leer y mantener.
Espero que os sirva de ayuda. Enjoy coding!
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)