基于ASP.NET Core MVC使用SignalR实现客户端元素显隐是否可行？

SignalR实现可行性 #

完全可以，这属于SignalR非常典型的适用场景，实现逻辑如下：

1. 先在你的ASP.NET Core MVC项目中引入SignalR，创建自定义Hub，定义客户端接收配置变更的方法名，示例Hub代码结构：

public class UISettingHub : Hub
{
    // 这里不需要额外写方法，服务端直接通过IHubContext发推送即可
}

2. 在你修改数据库配置的业务逻辑里（也就是你用EF更新配置参数的Service/Controller中），注入IHubContext<UISettingHub>，配置更新保存到数据库后，调用对应方法向客户端推送新的配置值：

// 配置更新保存到EF
_dbContext.UISettings.Update(setting);
await _dbContext.SaveChangesAsync();
// 向所有客户端推送更新
await _hubContext.Clients.All.SendAsync("OnUISettingUpdated", setting.SettingKey, setting.IsVisible);

3. 客户端侧页面加载时先从接口拉取全量初始UI配置，渲染对应元素的显隐状态，同时监听SignalR的OnUISettingUpdated事件，收到事件后直接操作DOM修改对应元素的显隐，无需刷新页面。

多实例部署场景下需要配置SignalR的Redis背板，保证所有实例连接的客户端都能收到推送。

其他可选实现方案 #

除了SignalR外，还有几种成熟方案可以选择，根据你的实时性要求和开发成本权衡即可：

• 定时轮询：前端按照固定周期（比如30s、1min）向后端接口拉取最新的UI配置，和本地存储的配置对比，有变更就更新DOM。实现成本最低，不需要额外引入实时通信组件，适合对更新延迟不敏感的场景，缺点是有延迟、会产生冗余请求。
• Server-Sent Events（SSE）：基于HTTP的单向长连接方案，浏览器原生支持，比SignalR更轻量，只需要服务端单向推送的场景下比SignalR开发更简单，也能实现秒级更新。
• 刷新拉取：如果配置更新频率极低，用户完全可以接受下次打开页面/刷新页面时生效，直接在页面渲染时从EF读取最新配置渲染即可，不需要任何额外开发，成本最低。

选型建议 #

• 要求配置更新后秒级生效，选SignalR
• 只需要单向推送、不想处理SignalR的复杂配置，选SSE
• 对实时性要求不高、想尽量少改代码，选定时轮询
• 配置几个月才改一次，直接用刷新拉取就行

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