c# - tutorial - Cómo implementar una API web principal ASP.NET "pura" mediante el uso de AddMvcCore()

asp.net core web api 2

Question

He visto muchos proyectos de la API web principal de ASP.NET que utilizan el servicio predeterminado AddMvc() sin darse cuenta de que usar AddMvcCore() es una opción superior debido al control sobre los servicios.

¿Cómo implementa exactamente una API web básica de ASP.NET utilizando AddMvcCore() y por qué es mejor?

Answer 1

¿Cuál es la diferencia entre AddMvc() y AddMvcCore() ?

Lo primero que hay que entender es que AddMvc() es solo una versión precargada de AddMvcCore() . Puede ver la implementación exacta de la extensión AddMvc() en el repositorio de GitHub .

Me gusta usar las plantillas VS predeterminadas tanto como el siguiente tipo, pero a veces necesitas saber cuándo es la elección incorrecta. He visto varias guías en línea que se inclinan más hacia un intento de "deshacer" estos servicios predeterminados en lugar de simplemente ir con una solución que simplemente no los implementa en primer lugar.

Con el advenimiento de ASP.NET Core como código abierto, realmente no hay una buena razón por la que no podamos quitar una capa y trabajar a un nivel inferior sin temor a perder "magia".

Definición de "minimal" y "puro"

Nota: Las definiciones están destinadas solo al contexto de esta respuesta. Principalmente por el bien de la claridad y ayudar a una mayor comprensión.

Esta respuesta se inclina más hacia "puro" y no "mínimo". Me gustaría describir por qué, así es más claro de lo que estoy hablando.

Mínimo. Una solución "mínima" sería una implementación que ni siquiera AddMvcCore() método AddMvcCore() . La razón de esto es que MVC no es realmente un componente "requerido" para ensamblar su propia API web, y ciertamente agrega algo de peso a su código con las dependencias adicionales. En este escenario, ya que no está utilizando el método AddMvcCore() , tampoco lo inyectaría en su aplicación, aquí

public void Configure(IApplicationBuilder app)
{
app.UseMvc(); // you don''t need this
}

Esto significaría mapear sus propias rutas y responder al context a su manera. Esto realmente no es un desafío en absoluto, pero no quiero sumergirme en eso, porque es un tema bastante extraño, pero aquí hay una pequeña muestra de una implementación mínima :

public void Configure(IApplicationBuilder app)
{
app.Map("/api", HandleMapApi);
// notice how we don''t have app.UseMvc()?
}
private static void HandleMapApi(IApplicationBuilder app)
{
app.Run(async context =>
{
// implement your own response
await context.Response.WriteAsync("Hello WebAPI!");
});
}

Para muchos proyectos, un enfoque "mínimo" significa que estamos renunciando a algunas de las características que se encuentran en MVC. Realmente tendría que sopesar sus opciones y ver si esta ruta de diseño es la correcta, ya que existe un equilibrio entre el patrón de diseño, la comodidad, la capacidad de mantenimiento, la huella del código y, lo que es más importante, el rendimiento y la latencia. En pocas palabras: una solución "mínima" significaría minimizar los servicios y el middleware entre su código y la solicitud.

Puro. Una solución "pura" (en el contexto de esta respuesta) es evitar todos los servicios y middleware predeterminados que vienen "pre-empaquetados" con AddMvc() al no implementarlos en primer lugar. En su lugar, usamos AddMvcCore() , que se explica más adelante en la siguiente sección:

Implementando nuestros propios servicios / middleware con AddMvcCore()

Lo primero que debe comenzar es configurar los servicios de ConfigureServices para usar AddMvcCore() . Si observa el repositorio de GitHub , puede ver que AddMvc() llama a AddMvcCore() con un conjunto estándar de servicios / middleware:

Estos son algunos de los servicios / middleware que se destacan como "innecesarios":

var builder = services.AddMvcCore();
builder.AddViews();
builder.AddRazorViewEngine();
builder.AddRazorPages();

Muchos de estos servicios predeterminados son excelentes para un proyecto web general, pero generalmente no son deseables para una API web "pura".

Aquí hay una implementación de muestra de ConfigureServices usando AddMvcCore() para una API web:

public void ConfigureServices(IServiceCollection services)
{
// Build a customized MVC implementation, without using the default AddMvc(),
// instead use AddMvcCore(). The repository link is below:
// https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc/MvcServiceCollectionExtensions.cs
services
.AddMvcCore(options =>
{
options.RequireHttpsPermanent = true; // this does not affect api requests
options.RespectBrowserAcceptHeader = true; // false by default
//options.OutputFormatters.RemoveType<HttpNoContentOutputFormatter>();
// these two are here to show you where to include custom formatters
options.OutputFormatters.Add(new CustomOutputFormatter());
options.InputFormatters.Add(new CustomInputFormatter());
})
//.AddApiExplorer()
//.AddAuthorization()
.AddFormatterMappings()
//.AddCacheTagHelper()
//.AddDataAnnotations()
//.AddCors()
.AddJsonFormatters();
}

La implementación anterior es principalmente un duplicado del método de extensión AddMvc() , sin embargo, he agregado algunas áreas nuevas para que otros puedan ver los beneficios adicionales de hacer esto.

• Formadores de entrada / salida personalizados. Aquí es donde puede hacer sus propios serializadores altamente optimizados (como Protobuf, Thrift, Avro, Etc) en lugar de usar la serialización JSON (o, lo que es peor, XML).
• Solicitud de manejo de encabezado. Puede asegurarse de que el encabezado Accept sea ​​reconocido o no.
• Manejo de autorizaciones. Puede implementar su propia autorización personalizada o puede aprovechar las funciones integradas.
• ApiExplorer. Para algunos proyectos, es probable que lo incluya, de lo contrario, es posible que algunas WebAPI no quieran esta función.
• Solicitudes de Origen Cruzado (CORS). Si necesita una seguridad más relajada en su WebAPI, puede habilitarla.

Esperemos que con este ejemplo de una solución "pura", pueda ver los beneficios de usar AddMvcCore() y sentirse cómodo con su uso.

Si se toma en serio el control sobre el rendimiento y la latencia mientras trabaja en la parte superior del host web de ASP.NET Core, tal vez una inmersión profunda en una solución "mínima" es donde se está tratando al borde de la tubería de solicitud, en lugar de dejar que se atasca por el middleware MVC.

Lectura adicional

Una vista visual de cómo se ve la canalización de middleware ... Según mis definiciones, menos capas significa "mínimo", mientras que "puro" es solo una versión limpia de MVC.

Puede leer más sobre esto en los Documentos de Microsoft: ASP.NET Core Middleware Fundamentals