.NET 9时代革新：四大传统设计模式已成过去式！

郑子铭

发布于 2025-06-20 09:15:38

1780

文章被收录于专栏：DotNet NB && CloudNativeDotNet NB && CloudNative

框架进化论

伴随每个新版本.NET的发布，微软都在用内置功能重塑软件开发范式。.NET 9延续这一传统，通过强化依赖注入、事件处理、中间件和Entity Framework Core等核心模块，让诸多经典设计模式失去了用武之地。

本文将深度解析这些被.NET 9"淘汰"的设计模式，揭示其背后技术演进的底层逻辑：

1. 单例模式 → 内置依赖注入
2. 工厂模式 → 服务容器与依赖注入
3. 观察者模式 → .NET事件系统与Reactive扩展
4. 仓储模式 → EF Core 8直接实现

1. 单例模式 → 依赖注入容器

为何曾经需要单例模式？

作为经典设计模式之首，单例模式通过强制唯一实例解决全局资源管理问题。典型应用场景包括： • 缓存管理 • 日志记录 • 配置中心 • 数据库连接池

传统手动实现存在三大痛点：

public classSingletonService
{
    privatestatic SingletonService? _instance;
    privatestaticreadonlyobject _lock = newobject();

    private SingletonService() { }
    
    publicstatic SingletonService Instance
    {
        get
        {
            lock (_lock)
            {
                if (_instance == null)
                {
                    _instance = new SingletonService();
                }
                return _instance;
            }
        }
    }
    
    public void DoSomething()
    {
        Console.WriteLine("单例方法调用");
    }
}

致命缺陷分析： • 线程安全依赖显式锁机制 • 生命周期管理完全手动化 • 单元测试时难以重置状态

现代方案：依赖注入革命

.NET 9内置容器原生支持单例生命周期：

// 服务注册
builder.Services.AddSingleton<SingletonService>();

// 服务消费
publicclassMyComponent
{
    privatereadonly SingletonService _service;

    public MyComponent(SingletonService service)
    {
        _service = service;
    }
    
    public void Execute() => _service.DoSomething();
}

技术红利： • 容器自动保证线程安全 • 实现真正的按需延迟初始化 • 支持模拟对象进行单元测试

2. 工厂模式 → 依赖注入与服务定位

传统工厂模式的困境

工厂模式用于封装对象创建逻辑，但存在致命缺陷：

public interfaceICar { void Drive(); }

publicclassBMW : ICar { public void Drive()=>Console.WriteLine("BMW驾驶体验"); }

publicstaticclassCarFactory
{
    public static ICar Create(string type) => 
        type switch { "BMW" => new BMW(), _ => thrownew ArgumentException() };
}

违背开闭原则的代价： • 新增车型必须修改工厂类 • 工厂方法膨胀导致维护困难 • 依赖关系隐式耦合

依赖注入新范式

// 服务注册
builder.Services.AddTransient<ICar, BMW>();

// 服务消费
public class CarService
{
    private readonly ICar _car;

    public CarService(ICar car) => _car = car;

    public void Start() => _car.Drive();
}

架构优势： • 0代码侵入实现多态扩展 • 依赖关系显式声明 • 测试时可直接注入Mock对象

3. 观察者模式 → 事件系统与响应式编程

传统观察者实现

public interface IObserver { void Update(string message); }

public class Publisher
{
    private List<IObserver> _observers = new();
    
    public void Subscribe(IObserver observer) => _observers.Add(observer);
    
    public void NotifyAll(string msg) => 
        _observers.ForEach(o => o.Update(msg));
}

隐藏的技术债务： • 手动维护订阅者列表 • 内存泄漏风险（未正确取消订阅） • 通知顺序无法控制

.NET原生解决方案

public classEventPublisher
{
    // 定义强类型事件
    publicevent EventHandler<string>? OnDataChanged;
    
    public void PublishChange(string data) =>
        OnDataChanged?.Invoke(this, data);
}

publicclassSubscriber
{
    public Subscriber(EventPublisher publisher) =>
        publisher.OnDataChanged += (s, e) => 
            Console.WriteLine($"收到更新：{e}");
}

关键技术突破： • 编译时类型安全保障 • 自动内存管理（+=/-=语法） • 支持异步事件处理

4. 仓储模式 → EF Core 8直接实现

仓储模式的兴衰史

传统仓储层设计：

public interfaceIUserRepo
{
    Task<User> GetByIdAsync(int id);
    Task AddAsync(User user);
}

publicclassUserRepo : IUserRepo
{
    privatereadonly AppDbContext _context;
    
    public UserRepo(AppDbContext context) => _context = context;
    
    public async Task<User> GetByIdAsync(int id) =>
        await _context.Users.FindAsync(id);
}

过度抽象的代价： • 增加无谓的抽象层次 • 需要额外维护接口与实现 • 抵消了EF Core的优势特性

EF Core 8实战

public class UserService
{
    private readonly AppDbContext _context;

    public UserService(AppDbContext context) => _context = context;

    public async Task<List<User>> GetAll() => 
        await _context.Users.ToListAsync();

    public async Task Add(User user) =>
        await _context.Users.AddAsync(user);
}

性能飞跃的关键： • 直接利用DbContext的变更追踪 • 内置延迟加载与批处理 • 减少一次内存分配层级

单元测试新范式

var options = new DbContextOptionsBuilder<AppDbContext>()
    .UseInMemoryDatabase(databaseName: "TestDb")
    .Options;

using var context = new AppDbContext(options);
var service = new UserService(context);

// 直接操作内存数据库完成测试
await service.Add(new User());
var count = await service.GetAll().CountAsync();