c# - 如何使用 AddMvcCore() 实现 "pure"ASP.NET Core Web API

Question

我见过很多使用默认的 ASP.NET Core Web API 项目 AddMvc()服务而没有意识到使用 AddMvcCore()由于对服务的控制，是一个更好的选择。

如何使用 AddMvcCore() 来实现 ASP.NET Core Web API和 为什么更好？

Answer 1

AddMvc()有什么区别和 AddMvcCore() ?

首先要了解的关键是AddMvc()只是AddMvcCore()的预装版本.您可以看到 AddMvc() 的确切实现分机地址为 GitHub repository .

我和下一个人一样喜欢使用默认的 VS 模板，但有时你需要知道什么时候是错误的选择。我在网上看到了几个指南，它们更倾向于尝试“撤消”这些默认服务，而不是仅仅使用一开始就没有实现它们的解决方案。

随着 ASP.NET Core 开源的出现，我们真的没有充分的理由不能剥离一层并在较低级别上工作而不担心失去“魔力”。

“最小”和“纯”的定义

注意:这些定义仅用于本答案的上下文。主要是为了清楚起见并帮助进一步理解。

这个答案更倾向于“纯粹”而不是“最小”。我想描述一下原因，这样我在说什么就更清楚了。

最小。 “最小”解决方案是实现 甚至不调用 AddMvcCore() 方法 .这样做的原因是 MVC 并不是组装您自己的 Web API 的真正“必需”组件，并且它肯定会为您的代码增加一些额外的依赖项。在这种情况下，由于您没有使用 AddMvcCore()方法，您也不会将其注入(inject)您的应用程序，这里

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

这意味着映射您自己的路线并响应 context以你自己的方式。这真的一点也不具有挑战性，但我不想深入研究它，因为它非常离题，但是 这是一个最小实现的小味道 :

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!");
    });
}

对于许多项目，“最小”方法意味着我们放弃了 MVC 中的一些功能。你真的必须权衡你的选择，看看你这个设计路径是否是正确的选择，因为设计模式、便利性、可维护性、代码占用空间以及最重要的性能和延迟之间存在平衡。 简单地说:“最小”解决方案意味着最小化代码和请求之间的服务和中间件。

纯的。 “纯”解决方案(就本答案的上下文而言)是避免使用 AddMvc()“预捆绑”的所有默认服务和中间件|通过不首先实现它。相反，我们使用 AddMvcCore() ，这将在下一节中进一步解释:

使用 AddMvcCore() 实现我们自己的服务/中间件

开始的第一件事是设置 ConfigureServices使用 AddMvcCore() .如果你看 GitHub repository ，你可以看到 AddMvc()电话AddMvcCore()使用一组标准的服务/中间件:

以下是一些“不需要”的服务/中间件:

var builder = services.AddMvcCore();

builder.AddViews();
builder.AddRazorViewEngine();
builder.AddRazorPages();

许多这些默认服务非常适合一般的 Web 项目，但通常不适合“纯”Web API。

这是 ConfigureServices 的示例实现使用 AddMvcCore()对于 Web API:

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();
}

上面的实现主要是 AddMvc() 的副本。扩展方法，但是我添加了一些新区域，以便其他人可以看到这样做的额外好处。

自定义输入/输出格式化程序。 在这里，您可以执行自己的高度优化的序列化程序(例如 Protobuf、Thrift、Avro 等)，而不是使用 JSON(或更糟的 XML)序列化。

请求头处理。 您可以确保 Accept header 是否被识别。

授权处理。 您可以实现自己的自定义授权，也可以利用内置功能。

应用程序浏览器。 对于某些项目，您可能会包含它，否则某些 WebAPI 可能不需要此功能。

跨域请求 (CORS)。 如果您需要更宽松的 WebAPI 安全性，您可以启用它。

希望通过这个“纯”解决方案的例子，您可以看到使用 AddMvcCore() 的好处。并乐于使用它。

如果您在 ASP.NET Core 的 Web 主机之上工作时认真对待对性能和延迟的控制，那么深入研究“最小”解决方案就是您在请求管道的边缘进行处理，而不是让它被 MVC 中间件所拖累。

补充阅读

中间件管道的可视化外观……根据我的定义，较少的层意味着“最小”，而“纯”只是 MVC 的一个干净版本。



您可以在 Microsoft 文档中阅读更多相关信息:ASP.NET Core Middleware Fundamentals