7

IStartupFilter 是库向应用程序添加中间件的机制的基础。根据文档“IStartupFilter 有助于确保中间件在应用程序请求处理管道开始或结束时库添加的中间件之前或之后运行”。

该机制是否允许您以无法从 Startup.Configure() 完成的任何方式操作管道？

如果重点是模块化，那么您似乎只是在通过 Startup.Configure() 进行耦合交易，以通过 IServicesCollection 进行耦合（需要调用 DI）。在简单的情况下（根据示例services.AddTransient<IStartupFilter, ...>()），可以从 ConfigureServices() 中删除对的调用，并且app.AddMiddleware<MyMiddleware>()可以添加以实现相同的功能，但复杂性和魔力更低。

该机制的重点是允许库应用条件来确定应该包含哪些中间件？如果是这样，它似乎缺乏 asp.net core 的习惯经济性和清晰的设计。

4

4 回答 4

6

在简单的情况下（根据示例），可以从 ConfigureServices() 中删除对 services.AddTransient() 的调用，并且可以添加 app.AddMiddleware() 以实现相同的功能，但复杂性和魔力更低。

这不是真的。

IStartupFilter使用和使用中间件之间有很大的区别。中间件是请求管道的一部分，这意味着它会在每个请求中执行。另一方面，IStartupFilter在应用程序启动时执行一次。

于 2020-02-20T20:08:28.767 回答
3

为了回答我自己的问题，我认为主要用例是使框架能够包含在构建时未知的程序集。文档在 aspnetcore/Fundamentals/Host nhance 中涵盖了这一点，该应用程序来自 ASP.NET Core 中的外部程序集和 IHostingStartup。（尽管文档没有提到IStartupFilter相关的StartupDiagnostics示例项目。

于 2018-09-05T06:30:38.053 回答
1

IStartupFilter 通常在您不希望应用程序作者进行任何干预时使用，即您不希望 app.Usexxxx() 被调用但不同的组件应该配置该中间件。现在，考虑一个场景，即使请求管道未执行，您也希望执行某些代码。让我们取一个不存在的 URI 并返回 404 错误，在这种情况下，请求处理管道不会被执行，但启动过滤器会被执行。

于 2020-03-02T11:16:23.433 回答
1

A simple answer is no, it doesn't add any new functionality.

The point behind the IStartupFilter is to run some stuff in the pre-defined order independently on how yours Startup.Configure method changes. It simply creates a sequence of methods they do actions on IApplicationBuilder (WebHostBuilder) to build the middleware pipeline. You can define action that will perform before or after the Startup.Configure method is called.

Your IStartupFilter implementation will look similarly to this:

public class ExampleStartupFilter : IStartupFilter
{
    public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)
    {
        return builder =>
        {
            // This will run before the Startup.Configure
            builder.UseMiddleware<PreStartupConfigureRegisteredMiddleware>();
            // This is Startup.Configure (or the next IStartupFilter.Configure in the sequence)
            next(builder);
            // This will run after Startup.Configure
            builder.UseMiddleware<AfterStartupConfigureRegisteredMiddleware>();
        };
    }
}

Arguably, as you have to register your IStartupFilter in the Startup.ConfigureServices method and the order the filters are registered is the order they will be performed, there is not much difference compare to the order of direct registrations of UseMiddleware in Startup.Configure.

The only benefit I can see is that you can register something that has absolutely run the first or the last in the pipeline, no matter what other middlewares you use. Then you don't have to worry about changes in the Configure method. It should, however, be used very scarcely.

Very good blog post explaining how the IStartupFilter works has been written by Andrew Lock, check it out here: https://andrewlock.net/exploring-istartupfilter-in-asp-net-core/

One thing Andrew points out is that you can register filter to run it prior to the AutoRequestServicesStartupFilter registered automatically by the WebHostBuilder. Not that I would be aware of an example where this would have a practical use.

于 2020-05-13T02:02:43.620 回答