c# - 为什么 AddMvc 需要 Action 而不是 MvcOptions？

Question

我正在学习 ASP.NET Core，我看到注册 MVC 服务如下所示:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc(options =>
    {
        options.MaxModelValidationErrors = 100;
    });
}

我的问题是，为什么 AddMvc方法需要 Action<MvcOptions> 形式的选项？为什么我不能只创建一个 MvcOptions 的实例？并将其传递给函数？

Answer 1

如果您查看 source对于 AddMvc ，您会看到它不会创建 MvcOptions 的实例给你:

public static IMvcBuilder AddMvc(this IServiceCollection services, Action<MvcOptions> setupAction)
{
    ...

    var builder = services.AddMvc();
    builder.Services.Configure(setupAction);

    return builder;
}

相反，它使用 IServiceCollection.Configure Hook 到更一般Options pattern in ASP.NET Core .在幕后，这添加了一个 IConfigureOptions<MvcOptions> 的实例。到依赖注入(inject)容器，它最终会在稍后的某个时间点运行您的委托(delegate)。

可以添加多个 IConfigureOptions<MvcOptions> 实例，将按注册顺序运行。还有 IServiceCollection.PostConfigure , 它注册了 IPostConfigureOptions<MvcOptions> 的实例- 这些实例将在所有 IConfigureOptions<MvcOptions> 之后运行实例 ( docs )。

这一切都提供了一些灵 active 。您可以设置代表管道以配置 MvcOptions按照设定的顺序，每个配置步骤可能来自其他项目等。您甚至可以自己调用 services.Configure<MvcOptions>(...)在您调用 AddMvc 之前等

---

将 MVC 服务添加到 DI 时，可以使用 AddMvc或 AddMvcCore .在内部，AddMvc电话 AddMvcCore , 所以我们可以想到 AddMvc作为 AddMvcCore 的某种扩展.

AddMvcCore adds its own configuration ，而不是创建 MvcOptions 的实例本身。它添加了一组 IConfigureOptions<MvcOptions> 和 IPostConfigureOptions<MvcOptions> 到依赖注入(inject)容器。

这两个接口(interface)用来组装一种形式的管道，其中所有IConfigureOptions<MvcOptions>首先运行(按照它们添加到 DI 的顺序)和所有 IPostConfigureOptions<MvcOptions>第二个运行(再次，按顺序)。这允许 AddMvcCore提供一些默认值(使用 IConfigureOptions<MvcOptions> )并提供对 MvcOptions 进行更改的能力一旦应用了所有其他配置(使用 IPostConfigureOptions<MvcOptions> )。

当您调用 AddMvc 时并提供一个委托(delegate)，该委托(delegate)将在 IConfigureOptions<MvcOptions> 之后运行添加者 AddMvcCore ，它提供了在您的应用程序中覆盖这些默认值的能力。