ASP.NET Core DI 工厂模式实战指南（高级开发者都在用的8种场景）-优快云博客

第一章：ASP.NET Core DI 工厂模式概述

在 ASP.NET Core 应用程序中，依赖注入（DI）是构建松耦合、可测试和可维护服务的核心机制。工厂模式与 DI 容器结合使用时，能够动态创建特定类型的实例，尤其适用于需要根据运行时条件选择不同实现的场景。该模式通过封装对象的创建逻辑，提升系统的灵活性和扩展性。

工厂模式的核心作用

解耦服务的定义与实例化过程
支持基于条件或参数返回不同的服务实现
避免在业务逻辑中直接使用 new 关键字创建对象

典型应用场景

当系统需要根据用户请求类型、配置项或环境变量加载不同服务实现时，工厂模式尤为适用。例如，日志记录器可根据运行环境返回 ConsoleLogger 或 FileLogger 实例。

注册工厂服务示例

在 Program.cs 中注册工厂委托，利用 DI 容器解析具体类型：

// 定义服务接口
public interface ILoggerService
{
    void Log(string message);
}

// 注册工厂：Func<string, ILoggerService>
builder.Services.AddTransient<ConsoleLogger>();
builder.Services.AddTransient<FileLogger>();
builder.Services.AddSingleton<Func<string, ILoggerService>>(provider => key =>
{
    return key switch
    {
        "console" => provider.GetService<ConsoleLogger>(),
        "file" => provider.GetService<FileLogger>(),
        _ => throw new ArgumentException("Invalid logger type")
    };
});

上述代码将一个工厂函数注册为单例服务，调用时传入字符串参数即可获取对应的日志实现。

优势与考量

优势	注意事项
提升运行时灵活性	需管理生命周期避免内存泄漏
增强代码可测试性	过度使用可能导致复杂度上升

第二章：DI 工厂模式核心原理与实现机制

2.1 理解依赖注入中的服务工厂本质

在依赖注入（DI）体系中，服务工厂并非简单的对象创建者，而是控制反转（IoC）容器中负责按需生成服务实例的核心机制。它屏蔽了对象构造的复杂性，使组件间依赖关系更加松耦合。

服务工厂的核心职责

延迟实例化：仅在首次请求时创建服务
生命周期管理：根据注册类型（瞬态、作用域、单例）决定实例复用策略
依赖解析：递归解析构造函数参数所需的其他服务

代码示例：自定义服务工厂


public interface IServiceFactory
{
    T CreateService<T>();
}

public class DefaultServiceFactory : IServiceFactory
{
    private readonly IServiceProvider _provider;
    
    public DefaultServiceFactory(IServiceProvider provider) => 
        _provider = provider;

    public T CreateService<T>() => 
        _provider.GetRequiredService<T>();
}

上述代码展示了工厂模式与 DI 容器的结合：DefaultServiceFactory 封装了 IServiceProvider 的具体调用逻辑，对外提供简洁的创建接口。通过依赖 IServiceProvider，实现了运行时动态解析，增强了扩展性与测试友好性。

2.2 IServiceFactory 与 IServiceProvider 协作原理

在依赖注入体系中， IServiceFactory 负责服务实例的创建策略定义，而 IServiceProvider 则承担运行时具体实例解析的职责。两者通过约定接口实现解耦协作。

核心协作流程

当请求获取服务时， IServiceProvider 内部委托 IServiceFactory 执行实际构造逻辑，确保生命周期管理（如单例、作用域、瞬态）正确应用。

public interface IServiceFactory
{
    object CreateInstance(IServiceProvider provider, Type serviceType);
}

上述代码定义了工厂的核心契约：接收服务提供者和目标类型，返回构建实例。该设计使创建逻辑可扩展。

典型协作场景

首次请求服务时，IServiceProvider 触发工厂创建并缓存实例（针对单例）
每次请求时，工厂根据生命周期策略决定是否复用已有实例
嵌套作用域中，工厂结合当前上下文提供隔离的服务实例

2.3 工厂模式在生命周期管理中的作用

工厂模式通过封装对象的创建过程，有效解耦系统组件间的依赖关系，在对象生命周期管理中发挥关键作用。它允许在运行时动态决定实例化哪个类，从而实现灵活的对象创建策略。

延迟初始化与资源控制

通过工厂统一管理对象创建时机，可实现延迟初始化（Lazy Initialization），避免资源浪费：

type ServiceFactory struct {
    instance *Service
}

func (f *ServiceFactory) GetInstance() *Service {
    if f.instance == nil {
        f.instance = &Service{} // 仅在首次调用时创建
    }
    return f.instance
}

上述代码确保服务实例在整个应用生命周期中唯一存在，提升内存效率。

生命周期钩子集成

创建前：执行配置校验
创建后：自动注册到服务容器
销毁前：释放数据库连接等资源

这种结构化流程增强了对象生命周期的可观测性与可控性。

2.4 基于泛型工厂的动态服务解析实践

在现代服务架构中，动态解析和创建服务实例是提升系统灵活性的关键。通过引入泛型工厂模式，可以在运行时根据类型参数构造对应的服务实现，避免硬编码依赖。

泛型工厂核心设计

该模式依托接口抽象与反射机制，结合注册-解析流程实现解耦：


type ServiceFactory struct {
    registry map[string]reflect.Type
}

func (f *ServiceFactory) Register(name string, svcType reflect.Type) {
    f.registry[name] = svcType
}

func (f *ServiceFactory) Create(name string) (interface{}, error) {
    svcType, ok := f.registry[name]
    if !ok {
        return nil, fmt.Errorf("service not registered")
    }
    return reflect.New(svcType.Elem()).Interface(), nil
}

上述代码中，`registry` 维护服务名称与类型的映射关系；`Create` 方法利用反射创建对应实例，支持运行时动态初始化。

应用场景与优势

微服务中按需加载不同数据处理器
插件系统中动态载入扩展模块
测试环境中快速替换模拟实现

该方案提升了代码可维护性，同时通过类型安全的泛型封装降低出错概率。

2.5 自定义工厂注册与运行时性能优化

在高并发场景下，对象的创建频率显著上升，传统的静态工厂模式难以满足动态扩展与性能需求。通过实现自定义工厂注册机制，可将类型创建逻辑延迟至运行时，并结合缓存策略减少重复开销。

工厂注册表设计

使用映射表维护类型构造器，支持按需注册与实例化：

var factoryRegistry = make(map[string]func() interface{})

func Register(name string, ctor func() interface{}) {
    factoryRegistry[name] = ctor
}

func Create(name string) interface{} {
    if ctor, exists := factoryRegistry[name]; exists {
        return ctor()
    }
    panic("unknown type: " + name)
}

上述代码中， Register 将构造函数按名称注册， Create 根据名称触发实例化，避免重复反射调用，提升运行时效率。

性能优化策略

采用 sync.Once 实现懒初始化，降低启动开销
结合对象池（sync.Pool）复用高频对象，减少 GC 压力
使用指针缓存已创建实例，适用于单例场景

第三章：常见应用场景深度解析

3.1 多租户环境下服务实例的动态切换

在多租户架构中，不同租户可能需要访问独立部署的服务实例以实现数据隔离与资源定制。动态切换机制通过路由策略实时定位目标实例，保障请求正确转发。

基于租户标识的路由分发

系统通常依据租户ID（Tenant ID）作为上下文关键字段，在网关层完成实例映射。例如，使用Spring Cloud Gateway结合Nacos注册中心实现动态路由：


@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
    return builder.routes()
        .route("tenant_route", r -> r.path("/api/{tenantId}/**")
            .filters(f -> f.rewritePath("/api/(?<tenant>[^/]+)/(?<path>.*)", "/${path}"))
            .uri("lb://service-${tenant}"))
        .build();
}

上述配置提取路径中的租户ID，并将请求负载均衡至对应命名的服务实例（如 service-tenantA），实现逻辑隔离。

实例切换的配置管理

通过集中式配置中心（如Apollo或Consul）动态更新路由规则，无需重启服务即可生效。以下为租户与实例映射示例：

租户ID	服务实例名	启用状态
tenant-a	order-service-prod	true
tenant-b	order-service-staging	false

3.2 条件化服务注册与运行时决策策略

在微服务架构中，条件化服务注册允许系统根据环境特征动态决定是否注册特定服务实例。这种机制提升了部署灵活性，支持多环境一致性配置。

基于条件的注册逻辑

通过评估运行时上下文（如配置标志、环境变量）控制服务暴露行为：


@Bean
@ConditionalOnProperty(name = "feature.cache.enabled", havingValue = "true")
public RedisCacheService cacheService() {
    return new RedisCacheService();
}

上述代码仅在配置项 `feature.cache.enabled` 为 `true` 时注册 Redis 缓存服务。`@ConditionalOnProperty` 注解实现条件判断，避免无效资源初始化。

运行时决策流程

初始化阶段 → 条件评估 → 注册/跳过 → 健康检查 → 服务发现

该流程确保只有满足预设条件的服务才进入服务注册中心，降低运维复杂度并提升系统稳定性。

3.3 领域事件处理器的按需激活实现

在复杂业务系统中，领域事件的处理往往涉及多个下游服务。为提升性能与资源利用率，采用按需激活机制可有效避免空转消耗。

事件订阅注册表

通过维护一个轻量级的处理器映射表，仅在特定事件发生时动态加载对应处理器：


type EventHandlerRegistry struct {
    handlers map[string]EventHandler
}

func (r *EventHandlerRegistry) Register(eventType string, handler EventHandler) {
    r.handlers[eventType] = handler
}

func (r *EventHandlerRegistry) Dispatch(event DomainEvent) {
    if handler, exists := r.handlers[event.Type()]; exists {
        handler.Handle(event)
    }
}

上述代码中，`Register` 方法将事件类型与处理器关联，`Dispatch` 在事件触发时按需调用对应逻辑，避免预加载所有处理器实例。

运行时激活策略

基于事件类型的反射机制动态实例化处理器
结合依赖注入容器实现生命周期管理
支持异步与同步混合执行模式

该设计提升了系统的模块化程度与扩展性，确保资源仅在必要时被占用。

第四章：高级实战技巧与最佳实践

4.1 结合策略模式实现支付网关动态路由

在复杂的支付系统中，面对多个第三方支付渠道（如支付宝、微信、银联），需根据业务场景动态选择最优网关。策略模式为此类需求提供了清晰的解耦方案。

策略接口定义

定义统一的支付策略接口，确保所有实现遵循相同契约：

type PaymentStrategy interface {
    Process(amount float64, orderID string) (string, error)
}

该接口抽象了支付处理的核心逻辑，各具体实现可独立封装不同网关的通信细节。

路由调度器设计

通过上下文对象动态绑定策略，实现运行时路由：

根据地域、金额、用户等级选择策略
支持运行时切换，无需修改调用方代码
便于扩展新支付方式，符合开闭原则

运行时流程

用户请求 → 解析路由规则 → 加载对应策略 → 执行支付 → 返回结果

4.2 使用工厂模式构建可扩展的数据访问层

在构建企业级应用时，数据访问层的可扩展性至关重要。工厂模式通过封装对象的创建过程，使系统能够在不修改核心逻辑的前提下支持多种数据源。

工厂模式的核心结构

工厂类根据运行时配置返回不同的数据访问实例，如关系型数据库、NoSQL 存储或内存缓存。

type DataStore interface {
    Save(data map[string]interface{}) error
    Find(id string) (map[string]interface{}, error)
}

type DataStoreFactory struct{}

func (f *DataStoreFactory) GetStore(storeType string) DataStore {
    switch storeType {
    case "mysql":
        return &MySQLStore{}
    case "redis":
        return &RedisStore{}
    default:
        return &InMemoryStore{}
    }
}

上述代码中， DataStoreFactory 根据传入的 storeType 返回对应的实现。这提升了模块解耦，便于测试与维护。

适用场景对比

数据源类型	适用场景	扩展难度
MySQL	事务密集型操作	低
Redis	高并发读写	中
MongoDB	非结构化数据存储	中

4.3 在中间件中集成依赖工厂实现请求级服务隔离

在现代Web应用中，确保每个HTTP请求拥有独立的服务实例是避免状态污染的关键。通过在中间件中集成依赖工厂，可实现请求级服务的动态创建与隔离。

依赖工厂的核心作用

依赖工厂负责按需生成服务实例，确保不同请求间不共享状态。典型流程如下：

请求进入中间件
工厂创建独立的服务容器
后续处理器使用该容器获取服务
请求结束时释放资源

Go语言示例

func DependencyMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        container := NewServiceContainer() // 每请求新建容器
        ctx := context.WithValue(r.Context(), "container", container)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

上述代码中， NewServiceContainer() 初始化一组服务实例，绑定到当前请求上下文，保证并发安全与隔离性。

4.4 基于配置驱动的服务工厂热插拔设计

在微服务架构中，动态扩展与运行时行为调整能力至关重要。基于配置驱动的服务工厂通过外部配置动态决定实例化何种服务实现，实现热插拔。

核心设计模式

采用工厂模式结合观察者机制，监听配置中心变更事件，触发服务重建。

type ServiceFactory struct {
    config *Config
    service Service
}

func (f *ServiceFactory) Reconfigure(newConfig *Config) {
    if newConfig.ServiceType != f.config.ServiceType {
        f.service = f.createService(newConfig)
    }
    f.config = newConfig
}

上述代码中， Reconfigure 方法接收新配置并判断服务类型是否变更，若变更则重新创建服务实例，实现无重启切换。

支持的协议类型

HTTP：适用于常规RESTful接口服务
gRPC：高性能二进制通信场景
WebSocket：需要长连接的实时交互

第五章：总结与架构演进思考

微服务治理的持续优化路径

在生产环境中，服务间调用链路复杂化促使我们引入更精细的流量控制机制。例如，在 Istio 中通过 VirtualService 实现金丝雀发布：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service-route
spec:
  hosts:
    - user-service
  http:
    - route:
        - destination:
            host: user-service
            subset: v1
          weight: 90
        - destination:
            host: user-service
            subset: v2
          weight: 10

该配置支持灰度验证新版本稳定性，降低上线风险。