Blazor中注入类服务(AppState)与组件通信的最佳实践咨询

1. 事件驱动方案是不是最佳实现？Blazor有没有更合适的原生方案？ #

Chris Sainty那套「单例/作用域AppState存全局数据+属性变更触发事件+组件监听后调用StateHasChanged()」的方案，其实已经成熟可靠，中小型应用完全够用。不过Blazor确实有更贴合.NET标准的原生实现方式：

• 用INotifyPropertyChanged接口：让你的AppState实现这个接口，属性变更时触发PropertyChanged事件；组件订阅这个事件，收到通知后调用StateHasChanged()。这种方式比自定义事件更符合.NET的通用规范，代码复用性也更高。
• Blazor没有原生的「全局状态双向绑定」功能（类似组件内的@bind）：@bind是针对组件间参数传递的双向绑定，依赖框架的参数变更检测和内置事件回调，没法直接套用到全局单例服务上。全局状态的变更通知必须自己手动写订阅、取消的逻辑。

如果是复杂场景（比如多模块联动、大量状态交互），可以考虑第三方状态管理库，但大多数情况下，事件驱动的方案（不管是自定义事件还是INotifyPropertyChanged）已经足够高效，还不用加额外依赖。

2. 用@implements IDisposable有啥弊端？为啥@bind不用手动处理？ #

主要弊端： #

• 内存泄漏风险：如果组件订阅了AppState的事件，但在Dispose里忘了取消订阅，AppState作为单例/作用域服务会一直持有组件的引用，导致组件实例没法被GC回收，跑久了就会内存泄漏。
• 手动实现容易出错：你得确保在Dispose里把所有订阅的事件、占用的资源都清干净，一旦漏了或者处理不当（比如空引用），就会炸运行时错误。

@bind不用手动处理的原因： #

@bind是Blazor框架内置的绑定机制，整个生命周期都是框架自动管的：

• 像输入框这类内置组件的@bind，框架会自动处理Value参数传递和ValueChanged事件的订阅、取消；
• 组件销毁的时候，框架会自动清理绑定相关的事件引用和资源，根本不需要你手动写IDisposable。

说白了，@bind的逻辑是框架帮你封装好的，而全局状态的事件订阅是你自己加的自定义逻辑，所以必须手动用IDisposable来清理，不然就会出问题。

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