在Asp.Net Core中使用ModelConvention实现全局过滤器隔

在Asp.Net Core的世界里，模型约定（ModelConvention）为我们提供了一种强大的工具，用以定制应用程序模型（ApplicationModel）的行为。当我们谈论Web API和MVC的集成时，我们面临的问题是如何在全局范围内应用过滤器，同时避免对MVC部分产生不必要的影响。让我们深入如何在保持MVC不变的为API部分添加全局过滤器。

在项目的迁移过程中，你可能会遇到这样的问题：在同时包含MVC和WebAPI的web程序中，需要为API部分添加接口验证过滤器IActionFilter。一种常见的方法是注册全局过滤器，以避免在每个控制器上手动添加代码。这样做会导致MVC控制器也受到过滤器的影响。尽管我们可以在过滤器中进行判断来区分MVC和API控制器，但这样的解决方案似乎并不理想。我们需要寻找一种更好的方法来实现这一目标。这时，ModelConvention闪亮登场。

让我们了解一下ApplicationModel。在ASP.NET Core MVC中，ApplicationModel代表MVC应用程序的各个组件。我们可以读取和操作这个模型来改变MVC元素的行为。默认情况下，MVC遵循一定的约定来确定哪些类被视为控制器，这些类上的哪些方法是动作，以及参数和路由如何表现。我们可以创建自己的约定并将其应用于全局或作为属性，以根据应用程序的需求自定义这些行为。

借助上述技术细节和知识，我们可以为自己的项目创建一个既强大又优雅的解决方案。这不仅能够帮助我们提高开发效率，还能提升代码的可读性和可维护性。对于想要在Asp.Net Core领域深入学习和实践的朋友们来说，这无疑是一个非常有价值的经验。希望这篇文章能为大家带来一些启示和灵感。ModelConvention：模型定制的基石

ModelConvention，如同其名，是操作模型的入口，也是一种契约精神的体现。它为我们的模型定制提供了多种可能，包括IApplicationModelConvention、IControllerModelConvention、IActionModelConvention、IParameterModelConvention以及IPageRouteModelConvention等。这些接口的核心方法Apply，正是模型定制的魔法所在。

以IControllerModelConvention为例，这个接口赋予了我们对ControllerModel进行定制的能力。ControllerModel，作为MVC架构中的核心组件，承载着控制器的重要信息。当我们实现IControllerModelConvention接口时，可以在Apply方法中获取到ControllerModel的实例，从而对其进行灵活的操作。

这个接口的应用场景非常广泛。我们可以更改控制器的名称，让程序中硬编码的控制器名失效；可以动态更新过滤器的集合，根据实际需求调整过滤规则；还可以更改路由规则，通过RouteValues字段实现更为灵活的路由配置。这些功能，无疑极大地提升了我们在开发过程中的灵活性和效率。

你可能会觉得，这与自定义过滤器看起来有些相似。但实际上，它们的生命周期和执行时机有着本质的区别。ModelConvention的执行时间要早于过滤器。在应用程序启动时，ModelConvention只需执行一次，无需随着每次请求而触发。换句话说，它的执行时间甚至在激活控制器之前，那时的过滤器还未被激活。它的调用时机发生在app.UseEndpoints()阶段，这是其独特之处。

```csharp

public class ApiControllerAuthorizeConvention : IApplicationModelConvention

{

public void Apply(ApplicationModel application)

{

foreach (var controller in application.Controllers)

{

if (controller.Filters.Any(x => x is ApiControllerAttribute) && !controller.Filters.Any(x => x is AessControlFilter))

{

controller.Filters.Add(new AessControlAttribute());

}

}

}

}

```

注意这里的 `Apply` 方法是应用于整个应用程序模型 `ApplicationModel` 的，它将遍历所有的控制器。你的原始实现是基于单个 `ControllerModel` 的。然后注册约定：

注册约定到应用程序中

在应用程序的服务注册中，你可以像下面这样注册你的自定义约定：

```csharp

services.AddMvc(options =>

{

// 添加自定义约定到MVC配置中

options.Conventions.Add(new ApiControllerAuthorizeConvention());

})

.SetCompatibilityVersion(CompatibilityVersion.Version_3_0); // 根据你的需求设置兼容性版本

```

这段代码将你的 `ApiControllerAuthorizeConvention` 添加到 MVC 的约定集合中，意味着当应用程序启动时，它将自动应用于所有控制器。你提到的关于类型不匹配的问题实际上可能并不存在，因为MVC框架在处理这些接口时具有灵活性。如果你的实现符合框架期望的约定模式（即修改控制器模型），那么它应该能够正常工作。如果你遇到具体的错误，请根据错误信息来调整代码。在Asp.Net Core的DI框架中，我们得以轻松实现全局过滤器管理，无需手动转换。通过深入研究其提供的扩展方法，我们可以发现一种更优雅的方式来处理全局过滤器，如AessControlFilter。下面，我将为你详细解读这一过程。

当我们进行代码调试时，我们发现在应用启动时，系统会遍历所有控制器并执行Apply操作。这为我们提供了一个机会，通过实现IApplicationModelConvention接口，我们可以在应用模型上应用全局过滤器。对于每一个控制器，我们可以检查其过滤器集合，然后根据需求添加新的过滤器。例如，如果控制器没有AessControlFilter过滤器，但我们想要为其添加ApiControllerAttribute过滤器时，我们可以遍历控制器集合并手动添加。这个过程虽然稍显复杂，但却是目前能想到的最佳解决方案。

接下来，我们遇到了一个挑战：如何在过滤器中使用依赖注入（DI）。在Asp.Net Core MVC框架中，ServiceFilter为我们提供了一个解决方案。ServiceFilter是一个特殊的过滤器，它可以通过构造函数接收一个Type类型的参数。这意味着我们可以在构造函数中注入真正需要的过滤器实例，例如AessControlFilter。为了使用ServiceFilter，我们需要将过滤器实例注入到DI容器中。这个过程可以通过在Startup.cs文件中的services.AddScoped方法完成。通过这种方式，我们可以优雅地在全局过滤器中使用DI自动注入。

这种方法的优点在于它提供了一种灵活且可维护的方式来管理全局过滤器。通过ServiceFilter和DI框架的结合使用，我们可以确保过滤器的实例化和配置与应用的生命周期紧密集成，而无需手动创建和管理过滤器实例。我们还可以利用DI框架的其他功能来扩展过滤器的功能，例如属性注入等。

虽然通过遍历目标控制器并手动添加Filter的方式可能不如一行代码就能实现的方式优雅，但这种方法确实提供了一种可行的解决方案。它允许我们在不改变框架核心逻辑的情况下，灵活地管理全局过滤器。我们还可以利用Asp.Net Core的DI框架和其他特性来进一步扩展过滤器的功能，从而提高应用的灵活性和可维护性。希望这篇文章能对你有所帮助，也希望大家多多支持我们的博客或网站。让我们一起更多关于Asp.Net Core的有趣功能和技巧！