C# 中介者模式实现方法 C#如何减少对象间的直接耦合

来源：这里教程网时间：2026-02-21 17:41:03 作者：

中介者模式的核心作用不是解耦，而是集中管理交互逻辑

中介者模式在 C# 中真正解决的不是“对象间有没有耦合”，而是“把原本散落在多个类中的交互规则，收拢到一个

Mediator

类里”。直接让两个类互相引用（比如

持有

，

持有

）是强耦合；但若改成两者都只依赖抽象

IMediator

，交互逻辑全由中介者调度，耦合就从“网状”变成了“星型”——这是可维护性的关键跃迁。

常见错误是把中介者写成空接口 + 一堆

if-else

分发，结果中介者自己变成上帝类。正确做法是：按业务场景划分职责，例如 UI 控件联动用

UIMediator

，领域事件协调用

DomainMediator

，不混在一起。

用泛型抽象中介者避免运行时类型转换

硬编码

object

参数或用

dynamic

会让中介者失去编译期检查，也难以重构。推荐用泛型约束定义消息契约：

public interface IMediator<in TRequest, out TResponse>
    where TRequest : IRequest<TResponse>
{
    TResponse Send(TRequest request);
}
<p>public interface IRequest<out TResponse> { }</p><p>public class LoginRequest : IRequest<LoginResult> { public string Username { get; set; } }
</p>

这样既保留类型安全，又避免为每种交互写独立方法（如

HandleLogin()

、

HandleLogout()

），后续加新请求只需新增实现类，不改中介者本身。

警惕“伪中介者”：别让中介者直接操作 UI 控件实例

在 WinForms 或 WPF 中，常见反模式是中介者直接持有

Button

、

TextBox

等控件引用。这会导致：

单元测试无法隔离（要 mock 控件就得引入整个 UI 栈） 中介者与具体 UI 框架绑定，换 Blazor 就得重写 生命周期错乱（控件被 dispose 后中介者还试图调用）

正确做法是让 UI 层暴露行为契约，例如：

public interface ILoginView
{
    event Action<string> OnLoginRequested;
    void ShowError(string message);
    void NavigateToHome();
}
<p>// 中介者只依赖这个接口，不碰任何 System.Windows.Forms 控件
public class LoginMediator
{
private readonly ILoginView _view;
private readonly IAuthService _auth;</p><pre class="brush:php;toolbar:false;">public LoginMediator(ILoginView view, IAuthService auth) => (_view, _auth) = (view, auth);
public void Initialize()
{
    _view.OnLoginRequested += async username =>
    {
        var result = await _auth.LoginAsync(username);
        if (result.Success) _view.NavigateToHome();
        else _view.ShowError(result.Message);
    };
}

}

中介者 + 事件总线更适合跨模块通信

当对象属于不同模块（如订单模块、库存模块、通知模块），且不共享上下文时，硬塞进一个中介者反而增加依赖。此时应组合使用：

模块内用轻量中介者协调紧密协作组件（如订单创建页的表单、校验、提交按钮） 模块间用事件总线（如
IEventBus.Publish<ordercreatedevent>()</ordercreatedevent>
）解耦中介者可以订阅事件（例如监听
OrderCreatedEvent
后触发本地 UI 更新），但不负责转发或转换事件

这种分层让变更影响范围清晰：改订单流程只动