Ardalis.Specification 项目中关于仓储自动保存的深度探讨

引言

在现代.NET应用程序开发中，数据访问层的设计一直是架构师和开发者关注的重点。Ardalis.Specification作为.NET生态中一个流行的规范模式实现库，其内置的RepositoryBase类提供了一套开箱即用的仓储实现。然而，关于仓储操作是否应该自动调用SaveChangesAsync()方法，社区中存在着不同的声音和实践方式。

问题背景

RepositoryBase类目前的设计在大多数方法（如AddAsync、UpdateAsync等）中都会自动执行SaveChangesAsync()操作。这种设计源于一个基本假设：在Web应用程序中，大多数请求通常只执行一个逻辑写入操作。这种设计简化了常见场景下的使用，开发者无需显式调用保存方法。

然而，这种设计也带来了一些限制：

1. 当需要处理领域事件时，开发者希望在持久化更改前触发这些事件
2. 在需要多个操作作为一个原子单元（事务）执行的场景下，自动保存会破坏事务边界
3. 无法灵活控制保存时机，导致性能优化空间受限

解决方案探讨

社区成员提出了几种可能的解决方案：

1. 继承重写方案

通过创建RepositoryBase的子类，重写所有涉及数据库更改的方法，移除其中的SaveChangesAsync()调用。这种方案的优点是不需要修改库代码，但缺点是需要维护大量重复代码，且存在字段隐藏的问题。

2. 方法参数控制方案

在每个方法中添加bool autoSave参数，让调用者决定是否立即保存。这种方法提供了最大的灵活性，但会导致API变得臃肿，且破坏了方法签名的一致性。

3. 配置选项方案

通过依赖注入引入配置选项，在应用启动时统一配置仓储的保存行为。这种方法保持了API的简洁性，但增加了配置的复杂性。

官方回应与演进

项目维护者对此问题做出了积极回应，指出了几个关键点：

1. 当前设计确实过于偏向特定使用模式，缺乏对工作单元模式的支持
2. 计划将仓储实现从核心库中分离，形成独立的Ardalis.Repository包
3. 未来可能提供多种风格的仓储实现，如支持工作单元的、自动保存的、可配置的等

在近期更新中，项目已经做出了一些改进：

1. 将DbContext和SpecificationEvaluator字段改为protected访问级别
2. 将所有方法标记为virtual，允许子类重写
3. 明确了仓储实现作为示例代码的定位，鼓励用户根据需要自定义

最佳实践建议

基于当前状态，建议开发者：

1. 对于简单场景，可以直接使用内置实现，享受开箱即用的便利
2. 对于需要事务控制或领域事件处理的场景，可以通过继承重写相关方法
3. 考虑在应用层引入工作单元模式，统一管理事务边界
4. 关注项目未来的Ardalis.Repository独立包，评估是否满足需求

总结

Ardalis.Specification项目中的仓储自动保存问题反映了软件设计中一个永恒的权衡：便利性与灵活性。当前解决方案通过提供足够的扩展点，让开发者能够根据具体需求调整行为，同时保持了核心功能的简洁性。随着项目的演进，我们期待看到更加模块化和可配置的仓储实现方案。