ARTICLE · 1285420
为什么复杂企业软件需要 Workbench,而不只是 Web 页面
过去十多年，Web 前端技术发生了很大的变化。从早期的 HTML、CSS 和 JavaScript，到Angular、React、Vue 等现代前端框架，再到各种 UI Component Library，开发一个功能完整的 Web 应用已经变得越来越容易。
但有,有一个问题始终存在：
当一个 Web 应用逐渐演变成一个复杂的企业级软件系统时，页面和组件的组织方式，是否仍然足以支撑整个应用？
一、Web 页面模式的局限
在一般的信息管理系统中，页面模式非常的有效。用户可以通过菜单进入不同页面，在页面中完成查询、编辑、提交等操作。页面之间通过路由进行切换，组件负责具体的交互和显示。
这种方式适用于业务边界清晰、交互相对独立的应用。但复杂企业软件往往不是这样。
以 PLM 系统为例，一个工程师可能需要同时处理：
产品结构和 配置； 工程对象及其属性； 零部件的版本和生命周期； - CAD 模型及其关联文件；
变更申请和工作流程； 设计文档和工程规范； 多个工程对象之间的关系。
这些工作并不是互相独立的页面操作，本质上是一个工程师的智力资源管理。用户可能需要同时打开多个对象，并且在不同视图之间切换，比较不同版本的数据，查看复杂的对象关系，并在多个编辑器中完成工作。
航空技术资料管理系统也是一样的。用户可能同时需要查看 AMM、IPC、FCOM、MEL 等技术资料，处理内容、适用性、版本、引用关系和发布状态。
航空的结构化运行手册管理和 PLM 在本质上并无不同，一个手册的编写人员通常需要同事处理：
手册目录和配置；
主题对象和属性；
主题的版本和生命周期；
主题的引用和法规的符合性关系；
主题和机型手册的关联性；
变更管理和工作流程；
多个主题和角色、业务系统以及协同业务的复杂关系；
如果每个业务模块都按照独立 Web 页面进行设计，会出现两种情况：
1.系统规模越大，前端交互方式就越容易出现差异；
2.将用户的操作和业务对象的管理以及流程在前端绑死，后端也将僵化。
二、组件统一不等于应用统一
目前很多企业软件项目都在建设统一的 Design System 或 UI Component Library。这些都很有价值，能够统一按钮、表格、树形控件、表单、对话框和视觉规范，也可以改善界面一致性，从而能减少重复开发。但组件的统一，只能解决 UI 层的问题，并不能解决以下问题：
应用如何组织多个业务模块？ 多个视图如何共同构成一个工作环境？ 用户打开的对象如何在不同视图之间共享？ 不同业务模块如何注册和扩展？ 命令、快捷键和上下文菜单如何统一管理？ 用户的工作布局如何保存和恢复？ 不同模块如何共享应用级服务？ 用户是在管理业务对象还是数据？ 系统的领域边界在哪里？
这些问题远远超出了组件库的概念，即使使用了完全相同的 UI 组件来实现一个系统应用，也仍然是由大量相互独立的页面拼接而成。
统一组件，并不意味着统一应用运行环境。
三、重新认识 Workbench
在复杂桌面软件中，Workbench 是一种成熟的架构思想，它并不是简单地把多个页面放在一个窗口里，而是通过 Workbench、Perspective、View、Editor、Command 和 Extension 等概念，组织整个应用的运行框架：
- Workbench 提供应用工作环境；
- Perspective 定义某种工作模式下的视图组织；
- View 提供特定的信息展示和操作能力；
- Editor 提供对象或内容的编辑能力；
- Command 定义统一的操作入口；
- Extension 允许业务功能向工作台注册和扩展；
用户可以通过调整视图来形成自己的独特的空间，从而满足自己特定的工作习惯； 驱使软件设计和开发工程师从习惯的处理数据转变为处理对象，从而划分出明确的业务领域。
这些概念共同构成了应用的组织模型，用户面对的不再是彼此孤立的页面，而是一个可以持续工作的环境。
这与复杂工程软件的实际使用方式更加接近。
四、现代 Web 是否也需要Workbench？
现代 Web 技术已经具备构建复杂工作台的基础。
React、Vue、Lit 等技术可以承担 UI 组件和业务视图的实现；浏览器提供了成熟的运行环境；各种 Docking、Layout 和State Management 技术也可以支持复杂交互。但这些技术通常解决的是局部问题。要构建一个完整的企业级 Workbench，还需要在它们之上建立统一的应用框架。
这个框架需要定义：
应用的组织结构； 视图和编辑器的生命周期； 工作模式和布局管理； 插件注册与扩展机制； 命令与交互体系； 应用上下文和运行时服务。
这意味着我们需要重新审视现代 Web 应用的前端架构。
五、从页面开发转向工作环境建设
复杂企业软件的前端，不应该仅仅被理解为一组页面和组件。它更像是一个专业工作环境。不同业务模块在这个环境中注册自己的功能，使用统一的交互机制，共享应用级服务，并按照统一的架构规则协同工作。
这种思路并不是要否定现代 Web 技术，也不是简单复刻传统桌面软件，只是希望解决的是一个更基础的问题：
