Scrutor库中支持编译视图的类扫描增强方案

背景介绍

Scrutor是一个流行的.NET依赖注入扩展库，它提供了基于约定的服务注册功能。在UI框架开发中，特别是使用XAML的框架如Avalonia、WPF等，视图类通常会被编译器生成额外的类型，这些类型在默认情况下不会被Scrutor扫描到。

问题分析

在Avalonia等UI框架中，XAML文件会被编译成C#代码，生成部分类实现。这些编译器生成的类型具有以下特点：

1. 带有CompilerGeneratedAttribute特性
2. 继承自基础UI类如Window或UserControl
3. 默认情况下会被Scrutor的类扫描机制过滤掉

这导致开发者无法通过常规的AddClasses方法注册这些视图组件，需要手动逐个注册，失去了约定优于配置的优势。

解决方案演进

初始方案：新增API方法

最初提出的解决方案是增加两个新的API方法：

IImplementationTypeFilter IncludeCompilerGeneratedSubclassesOf(params Type[] types);
IImplementationTypeFilter IncludeCompilerGeneratedSubclassesOf(IEnumerable<Type> types);

这种方法虽然解决了问题，但存在以下不足：

1. 引入了新的专用API，增加了API表面复杂度
2. 不够灵活，无法与其他筛选条件组合使用

优化方案：利用现有API

更优的解决方案是调整Scrutor内部实现，将编译器生成类型的过滤推迟到其他筛选条件之后执行。这样开发者可以使用现有的API组合来实现需求：

services
    .Scan(scan => scan
        .FromAssemblyOf<App>()
        .AddClasses(classes => classes
            .InNamespaces("MyApp.Desktop.Pages")
            .WithAttribute<CompilerGeneratedAttribute>()
            .AssignableToAny(typeof(Window), typeof(UserControl))
        )
        .AsSelf()
        .WithTransientLifetime()
    );

这种方案的优势在于：

1. 完全利用现有API，无需新增方法
2. 更灵活，可以与其他条件自由组合
3. 更明确地表达了筛选意图

实现细节

在实现上，主要做了以下调整：

1. 修改了类型扫描流程，将编译器生成类型的过滤从初始阶段移除
2. 允许WithAttribute<CompilerGeneratedAttribute>()显式包含这些类型
3. 保持了默认情况下排除编译器生成类型的行为，确保向后兼容

最佳实践

当需要在UI框架中使用此功能时，建议：

1. 明确限定命名空间范围，避免扫描过多类型
2. 精确指定基类，如Window、UserControl等
3. 考虑使用AsSelf()而非AsSelfWithInterfaces()，因为编译器生成的类型通常会实现许多框架内部接口
4. 对于性能敏感场景，尽量缩小扫描范围

总结

Scrutor通过灵活的API设计，无需新增专用方法就解决了编译器生成视图类型的注册问题。这一改进展示了良好API设计的重要性——通过合理的默认行为和可组合的筛选条件，既能满足常见需求，又能处理特殊场景。对于使用XAML框架的开发者来说，这一特性大大简化了视图组件的依赖注入配置工作。