.NET Repository Pattern非数据库场景应用及HTTP请求实现最佳实践

Repository模式的核心定位与适用范围 #

首先明确Repository模式的核心是领域层与外部数据交互的抽象层，职责是屏蔽底层数据来源的实现细节，让领域层仅依赖业务定义的接口，无需感知数据的实际存储/获取方式。
它从设计之初就不局限于数据库场景，所有需要对外获取、存储业务领域实体的场景都可以使用，除了数据库之外的常见适用场景包括：

• 分布式缓存（Redis、Memcached等）的实体读写
• 本地文件（CSV、JSON、Excel等）的结构化数据存取
• 配置中心、密钥管理服务的配置数据拉取
• 第三方API的领域实体获取/更新

第三方API调用场景的实现方案 #

针对对接多个第三方HTTP API的场景，具体用什么模式可以根据调用目的区分：

适合用Repository封装的场景 #

如果你调用第三方API的核心目的是获取或操作和你的业务领域模型完全对齐的实体，比如你的领域层定义了ExchangeRate实体，调用第三方汇率API就是为了获取该实体的最新数据，完全可以用Repository模式实现：

1. 在Domain/Core层定义接口IExchangeRateRepository，声明业务需要的方法比如Task<ExchangeRate> GetByCurrencyPairAsync(string baseCurrency, string targetCurrency)
2. 在Infrastructure层实现HttpExchangeRateRepository，在这个类里封装HTTP请求逻辑、参数构造、返回结果转领域实体、异常处理的所有代码，依赖IHttpClientFactory发送请求即可
3. 上层业务只依赖IExchangeRateRepository接口，完全感知不到底层是调用第三方API还是查询本地数据库，符合依赖倒置原则，后续如果要加本地缓存兜底也只需要修改实现类，不需要改动上层逻辑。

更适合用服务网关/反腐败层的场景 #

如果调用第三方API不是单纯的实体CRUD，而是包含特定的业务动作，比如调用支付API发起支付请求、调用短信服务商API发送验证码、调用物流API下单寄件，这类带有明显服务调用属性、需要和第三方系统做复杂协议适配的场景，更适合用服务网关（Service Gateway） 或者反腐败层（Anticorruption Layer） 模式：

• 同样把接口定义在Domain/Core层，命名上可以区分于Repository，比如IPaymentGateway、ISmsService
• 实现类放在Infrastructure层，专门处理第三方接口的参数适配、签名生成、错误码转换、结果映射逻辑，避免第三方接口的定义侵入你的领域模型。

.NET落地最佳实践 #

• 所有HTTP请求统一使用.NET内置的IHttpClientFactory管理HttpClient生命周期，避免手动实例化HttpClient导致的端口耗尽问题
• 可以结合Polly库在基础设施层的实现类里封装重试、熔断、限流等弹性处理逻辑，不需要上层业务关心
• 所有第三方交互的配置（接口地址、密钥、超时时间等）都通过IOptions模式注入，不要硬编码在实现类里

相关学习资料 #

可以参考微软官方.NET架构指南、《领域驱动设计：软件核心复杂性应对之道》、《.NET微服务：容器化.NET应用架构指南》，这些资料中都包含非数据库场景的Repository、跨服务交互模式的相关实现说明和示例。

内容的提问来源于stack exchange，提问作者yuribsl