ASP.NET 2.0 Web Parts迁移Blazor可行性及替代方案咨询

Blazor Server完全可以实现ASP.NET 2.0 Web Parts的全部核心能力，不需要额外切换React/Angular技术栈，以下是具体实现路径和备选方案说明。

Blazor没有内置和旧版Web Parts 1:1对应的同名功能集，但所有核心需求都可以基于原生能力低成本实现，迁移时可以直接复用原有.NET业务逻辑，工作量远低于前后端分离方案。

1. 终端用户自定义页面、用户级个性化UI实现 #

• 首先将原有每个Web Part的业务逻辑封装为独立的可复用Razor组件，给所有组件套统一的Widget容器：容器实现标题栏、最小化/关闭/配置入口、拖拽占位等通用交互，通过Blazor JS互操作能力对接成熟的前端拖拽交互库，即可实现用户拖拽调整组件位置、从组件目录选择添加新组件到页面的交互，和旧版Web Parts的编辑体验一致。
• 用户个性化数据持久化直接对接ASP.NET Core身份系统：为每个登录用户存储专属的页面配置，包括已添加的组件列表、组件排列顺序、位置尺寸、每个组件的个人配置参数。页面初始化时按当前用户身份拉取配置，动态渲染对应组件即可，完全实现每位用户独立定制UI的效果。
• 目前多数成熟的Blazor开源组件库都已经提供了开箱即用的可拖拽Widget容器组件，不需要从零编写布局交互的基础逻辑。
• 实际迁移时不需要兼容旧版Web Parts的个性化提供程序、控件目录这些过时架构，所有逻辑都可以按.NET 6+的原生规范实现，后续维护成本比老系统低很多。

2. 组件间通信机制实现 #

你提到的跨Web Part传值（比如输入框内容作为数据网格过滤条件）的场景，Blazor原生能力支持得比旧版Web Parts更灵活：

• 存在父子嵌套关系的组件，直接通过[Parameter]传值、EventCallback触发事件即可完成通信
• 平级无嵌套关系的组件（对应原来平级放置的Web Parts），注册一个生命周期为Scoped的内存状态容器服务即可实现中转：输入类组件将用户输入的过滤条件写入状态容器并触发变更通知，数据网格类组件订阅变更通知，收到参数后自动刷新绑定数据即可，逻辑比旧版Web Parts需要配置连接点的方式更简单直观。
• Blazor Server采用Circuit长连接模式，上述状态容器天然在用户当前访问会话内生效，不需要额外做会话状态维护。

如果因技术栈偏好选择React/Angular路线，也可以通过前后端分离架构实现等效能力，整体迁移工作量会明显高于Blazor Server方案：

• 架构层面采用ASP.NET Core Web API作为后端，负责业务逻辑处理、用户个性化配置存储、权限校验，前端层用React或Angular实现页面渲染与交互
• 个性化UI实现：将原有Web Part封装为独立的前端组件，对接前端拖拽布局库实现组件添加、删除、位置调整的编辑交互；所有用户的布局配置、组件个性化参数通过接口持久化到数据库，用户登录后拉取对应配置动态渲染
• 组件间通信实现：React技术栈可以通过Context API、轻量状态管理方案实现跨组件消息同步；Angular技术栈可以通过共享服务结合RxJS的订阅发布机制实现平级组件传值，满足过滤参数同步这类场景需求。
• 该方案的缺点是原有服务端UI逻辑无法复用，需要全部在前端重写，业务逻辑也需要额外封装为API接口，整体迁移周期更长。

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