C#中外观模式的核心是厘清子系统、外观、客户端三者边界；其价值在于封装固定协作链、实现解耦与契约隔离，而非简单转发。
直接说结论：C# 中实现外观模式，核心不是写多少代码，而是**明确谁是子系统、谁是外观、谁是客户端**——三者边界一旦模糊，Facade 就会退化成普通工具类，失去解耦价值。
什么时候该用 Facade 而不是直接调用子系统
典型信号是：客户端每次完成一个业务动作，都得手动组合多个子系统调用，且顺序/条件/异常处理逻辑重复出现。比如：
- 用户注册成功后，必须依次调用
UserService.Create()→EmailService.SendWelcome()→AnalyticsService.Track("register") - 支付流程中，要协调
PaymentGateway.Charge()、InventoryService.LockStock()、OrderService.CreateOrder()，且任一失败需回滚前序操作
这些逻辑如果散落在各处，改一个子系统接口，所有调用点都要同步改。而 Facade 的作用，就是把这类“固定协作链”收口到一个地方。
Facade 类里不该放什么
常见误用是把 Facade 写成大杂烩：
- 不封装具体子系统实例，而是直接在方法里 new 子系统对象（导致无法单元测试、无法替换实现）
- 在
Facade中写业务规则判断（如 “如果用户等级 > 5 才发短信”，这属于领域逻辑，应交给领域服务） - 暴露子系统内部类型（如返回
SubSystemA.Result而非FacadeResult），让客户端又绕过外观直连子系统 - 给每个子系统方法都套一层同名转发（
DoA()→subA.DoA()），没做任何协调或简化
真正有效的 Facade 必须有「协调性」：它知道子系统之间怎么配合，而不是简单转发。
如何让 Facade 支持可测试与可替换
关键在构造函数注入子系统依赖，而非硬编码：
public class OrderFacade
{
private readonly IOrderService _orderService;
private readonly IPaymentGateway _paymentGateway;
private readonly IInventoryService _inventoryService;
<pre class="brush:php;toolbar:false;">public OrderFacade(IOrderService orderService,
IPaymentGateway paymentGateway,
IInventoryService inventoryService)
{
_orderService = orderService;
_paymentGateway = paymentGateway;
_inventoryService = inventoryService;
}
public async Task<OrderResult> PlaceOrder(OrderRequest request)
{
// 协调逻辑集中在这里：锁库存 → 支付 → 创建订单 → 异常清理
var stockLocked = await _inventoryService.TryLock(request.Items);
if (!stockLocked) throw new InvalidOperationException("库存不足");
var paymentResult = await _paymentGateway.Charge(request.Payment);
if (!paymentResult.Success)
{
await _inventoryService.ReleaseLock(request.Items);
throw new InvalidOperationException("支付失败");
}
return await _orderService.Create(request);
}}
这样写之后：
- 单元测试可传入 Mock 实现，验证协调逻辑是否正确
- 替换支付网关时，只需改 DI 容器注册，
OrderFacade本身不用动 - 子系统升级接口（如
IInventoryService新增参数），只要协调逻辑不变，OrderFacade方法签名可保持稳定
为什么 Facade 不该是静态类
静态 Facade 看似简洁，但会带来三个实际问题：
- 无法注入依赖，只能靠
new或 Service Locator，破坏可测性 - 无法实现多租户隔离（比如不同客户走不同支付通道，静态类做不到运行时切换）
- 和 ASP.NET Core 的生命周期管理冲突（
Scoped/Transient子系统无法被静态类持有）
哪怕只是临时快速原型，也建议用实例类 + 构造函数注入，否则后期重构成本远高于初期多写的两行代码。
最易被忽略的一点：外观模式的价值不在“封装了几个类”，而在于它定义了**子系统协作的契约边界**。这个边界一旦确立，子系统内部可以任意重构，只要 Facade 的输入输出不变，上层就完全无感——这才是它真正扛住复杂度的地方。
