如何实现“纯"的解决方案?使用AddMvcCore()的ASP.NET Core Web API [英] How to implement a "pure" ASP.NET Core Web API by using AddMvcCore()

问题描述

我已经看到许多使用默认AddMvc()服务的ASP.NET Core Web API项目，但没有意识到由于对服务的控制，使用AddMvcCore()是更好的选择.

I've seen a lot of ASP.NET Core Web API projects that use the default AddMvc() service without the realizing that using AddMvcCore() is a superior option due to the control over services.

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

推荐答案

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

首先要了解的关键是AddMvc()只是AddMvcCore()的预加载版本.您可以在AddMvc()扩展的确切实现. ="noreferrer"> GitHub存储库.

What is the difference between AddMvc() and AddMvcCore()?

The first thing key thing to understand is that AddMvc() is just a pre-loaded version of AddMvcCore(). You can see the exact implementation of the AddMvc() extension at the GitHub repository.

我喜欢和下一个家伙一样使用默认的VS模板，但是有时您需要知道什么时候是错误的选择.我在网上看到了几本指南，它们更倾向于尝试撤消"这些默认服务，而不是仅仅采用一种根本没有实现它们的解决方案.

I like using default VS templates as much as the next guy, but sometimes you need to know when it's the wrong choice. I have seen several guides online that lean more towards an attempt to "undo" these default services rather than just going with a solution that just does not implement them in the first place.

随着ASP.NET Core开源的出现，确实没有充分的理由说明为什么我们不能剥离一层并在较低的级别上工作而不必担心失去魔术".

With the advent of ASP.NET Core being open source, there really isn't a good reason why we can't peel back a layer and work at a lower level without fear of losing "magic".

注意:定义仅用于此答案的上下文.主要是为了清楚起见并有助于进一步理解.

此答案更倾向于纯"而不是最小".我想描述原因，因此更清楚我在说什么.

This answer leans more towards "pure" and not "minimal". I'd like to describe why, so it's clearer what I'm talking about.

最小.最小"解决方案是甚至根本不需要 AddMvcCore() 方法的实现.这样做的原因是，MVC并不是组装您自己的Web API的真正必需"组件，并且肯定会通过附加的依赖关系为您的代码增加一些分量.在这种情况下，由于您没有使用AddMvcCore()方法，因此也不会将其注入到您的应用程序中，在这里

Minimal. A "minimal" solution would be an implementation that does not even call upon the AddMvcCore() method at all. The reason for this, is that MVC is not really a "required" component to assembling you own Web API, and it certainly adds some weight to your code with the additional dependencies. In this scenario, since you're not using the AddMvcCore() method, you also would not inject it into your application, here

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

这意味着映射您自己的路线并以您自己的方式响应context.这确实不是什么挑战，但我不想深入探讨它，因为它是题外话，但是这里只是最小实现的一点味道:

This would mean mapping your own routes and responding to the context in your own way. This really isn't challenging at all, but I don't want to dive into it, because it's quite off-topic, but here is a tiny taste of a minimal implementation:

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中的某些功能.您真的必须权衡一下选择，看看您的设计路径是否是正确的选择，因为在设计模式，便利性，可维护性，代码占用量以及最重要的性能和延迟之间要达到平衡. 简单地说:最小"的解决方案意味着将代码和请求之间的服务和中间件最小化.

For many projects, a "minimal" approach means we are giving up some of the features found in MVC. You would really have to weigh your options and see if you this design path is the right choice, as there is a balance between design pattern, convenience, maintainability, code footprint, and most importantly performance and latency. Simply put: a "minimal" solution would mean minimizing the services and middleware between your code and the request.

纯.一种纯"解决方案(就此答案而言)是通过不实施而避免与AddMvc()进行预捆绑"的所有默认服务和中间件.首先.相反，我们使用AddMvcCore()，这将在下一部分中进一步解释:

Pure. A "pure" solution (as far as the context of this answer) is to avoid all the default services and middleware that come "pre-bundled" with AddMvc() by not implementing it in the first place. Instead, we use AddMvcCore(), which is explained further in the next section:

开始的第一件事是将ConfigureServices设置为使用AddMvcCore().如果您查看 GitHub存储库，您可以看到AddMvc()使用一组标准的服务/中间件调用AddMvcCore():

The first thing to get started is to setup ConfigureServices to using AddMvcCore(). If you look at the GitHub repository, you can see that AddMvc() calls AddMvcCore() with a standard set of services / middleware:

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

Here are some of the services / middleware that stands out as "unneeded":

var builder = services.AddMvcCore();

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

许多默认服务对于一般的Web项目来说非常有用，但对于纯" Web API通常是不希望的.

Many of these default services are great for a general web project, but are usually undesirable for a "pure" Web API.

以下是使用AddMvcCore()的Web API的ConfigureServices的示例实现:

Here is a sample implementation of ConfigureServices using AddMvcCore() for a 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()扩展方法的重复，但是我添加了一些新的领域，以便其他人可以看到这样做的更多好处.

The implementation above is mostly a duplicate of the AddMvc() extension method, however I have added a few new areas so that others can see the added benefits of doing this.

• 自定义输入/输出格式化程序.在这里，您可以执行自己的高度优化的序列化程序(例如Protobuf，Thrift，Avro，Etc)，而不使用JSON(或更糟糕的XML)序列化./li>
• 请求标头处理..您可以确保是否识别出Accept标头.
• 授权处理..您可以实施自己的自定义授权，也可以利用内置功能.<​​/li>
• ApiExplorer..对于某些项目，您可能会包含它，否则某些WebAPI可能不需要此功能.
• 跨域请求(CORS).如果您需要WebAPI上更宽松的安全性，则可以启用它.

• Custom Input/Output Formatters. This is where you can do your own highly optimized serializers (such as Protobuf, Thrift, Avro, Etc) instead of using JSON (or worse XML) serialization.
• Request Header Handling. You can make sure that the Accept header is recognized, or not.
• Authorization Handling. You can implement your own custom authorization or can take advantage of the built-in features.
• ApiExplorer. For some projects, you may likely include it, otherwise some WebAPI's may not want to this feature.
• Cross-Origin Requests (CORS). If you need a more relaxed security on your WebAPI, you could enable it.

希望通过本纯"解决方案示例，您可以看到使用AddMvcCore()的好处，并且对使用它感到满意.

Hopefully with this example of a "pure" solution, you can see the benefits of using AddMvcCore() and be comfortable with using it.

如果您在使用ASP.NET Core的Web主机时认真考虑控制性能和延迟的问题，那么也许可以深入研究最小"解决方案，从而在请求管道的边缘进行处理，而不是让它被MVC中间件所困扰.

If you're serious about control over performance and latency while working on top of ASP.NET Core's web host maybe a deep dive into a "minimal" solution is where you're dealing right at the edge of the request pipeline, rather than letting it get bogged down by the MVC middleware.

直观地看一下中间件管道的样子……按照我的定义，更少的层意味着最小"，而纯"只是MVC的干净版本.

A visual look at how the middleware pipeline looks like... As per my definitions, less layers means "minimal", whereas "pure" is just a clean version of MVC.

您可以在Microsoft文档中阅读有关它的更多信息: ASP.NET核心中间件基础知识

You can read more about it on the Microsoft Documents: ASP.NET Core Middleware Fundamentals

这篇关于如何实现“纯"的解决方案?使用AddMvcCore()的ASP.NET Core Web API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！