AddMvcCore（）を使用して「純粋な」ASP.NET Core Web APIを実装する方法

違いは何であるAddMvc()とはAddMvcCore()？

最初に理解しておくべき重要なことは、AddMvc()がプリロードされたバージョンであることAddMvcCore()です。GitHubリポジトリでAddMvc()拡張機能の正確な実装を確認できます。

私は次の人と同じくらいデフォルトのVSテンプレートを使用するのが好きですが、時々それが間違った選択であるかを知る必要があります。私はオンラインでいくつかのガイドを見てきましたが、これらのガイドを実装していないソリューションを使用するのではなく、これらのデフォルトサービスを「元に戻す」ことを目的としています。

ASP.NET Coreがオープンソースになったことで、「魔法」を失うことを恐れずにレイヤーを剥がして下位レベルで作業できない理由は、実際にはありません。

「最小」と「純粋」の定義

注：定義は、この回答のコンテキストのみを対象としています。ほとんどの場合、明確にするため、およびさらに理解を深めるためです。

この答えは、「最小」ではなく「純粋」に傾いています。その理由を説明したいと思いますので、私が話していることがより明確になります。

最小限。「最小限の」ソリューションは、 AddMvcCore() メソッドをまったく呼び出さない実装です。その理由は、MVCは実際に独自のWeb APIを組み立てるための「必須」コンポーネントではなく、追加の依存関係によってコードにある程度の重みが加わることです。このシナリオでは、AddMvcCore()メソッドを使用していないため、ここにアプリケーションに注入しません。

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のリポジトリには、その見ることができるAddMvc()の呼び出しをAddMvcCore()サービス/ミドルウェアの標準セットで：

以下は、「不要」と目立つサービス/ミドルウェアの一部です。

var builder = services.AddMvcCore();

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

これらのデフォルトサービスの多くは、一般的なWebプロジェクトには最適ですが、通常「純粋な」Web APIには望ましくありません。

以下は、Web APIのConfigureServices使用のサンプル実装ですAddMvcCore()。

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()拡張メソッドの複製ですが、他の人がこれを行うことの追加の利点を見ることができるように、いくつかの新しい領域を追加しました。

• カスタム入力/出力フォーマッタ。これは、JSON（またはより悪いXML）シリアライゼーションを使用する代わりに、独自に高度に最適化されたシリアライザ（Protobuf、Thrift、Avroなど）を実行できる場所です。
• リクエストヘッダーの処理。Acceptヘッダーが認識されているかどうかを確認できます。
• 承認の処理。独自のカスタム認証を実装することも、組み込み機能を利用することもできます。
• ApiExplorer。一部のプロジェクトでは、それを含める可能性があります。そうでない場合、一部のWebAPIはこの機能を必要としません。
• Cross-Origin Requests（CORS）。WebAPIでよりリラックスしたセキュリティが必要な場合は、それを有効にすることができます。

この「純粋な」ソリューションの例がうまくいけば、それを使用することの利点をAddMvcCore()理解し、使用に慣れることができます。

ASP.NET CoreのWebホストで作業しているときにパフォーマンスとレイテンシの制御に真剣に取り組んでいる場合は、「最小限の」ソリューションの詳細を調べて、リクエストパイプラインの端で対処するのではなく、 MVCミドルウェアに行き詰まってしまいます。

追加の読書

ミドルウェアパイプラインがどのように見えるかを視覚的に見て...私の定義によれば、レイヤーが少ないということは「最小」を意味しますが、「純粋」はMVCのクリーンバージョンにすぎません。

詳細については、Microsoft Documents：ASP.NET Core Middleware Fundamentalsを参照してください。