大量表单场景下Razor Pages动态加载子视图方案选型咨询

传统MVC是否更合适？ #

是的，对于你这种需要上百个独立表单、每个表单有专属提交/审批/处理逻辑的场景，传统MVC的Controller+Action模式会更适配。MVC天然支持为不同表单拆分独立的处理单元，每个表单对应自己的Controller，逻辑边界清晰，不用强行在Razor Pages的单个页面类里堆砌复杂逻辑，也避免了ViewComponent只能通过Invoke渲染、无法承载完整业务流程的局限。

其他更合适的实现方案 #

方案1：Razor Pages + 独立表单服务类（推荐保留Razor Pages时使用） #

• 为每个表单创建独立的表单服务类（如FormOrderService、FormLeaveService），并定义统一接口IFormService，包含SubmitAsync、GetFormDetailAsync、ApproveAsync等通用方法。
• 在共享的提交/查看Razor Page后台类中，根据路由参数（如formType）通过依赖注入获取对应表单的服务实例，调用对应方法处理业务逻辑。
• 视图部分用Partial View或ViewComponent动态渲染表单UI，ViewComponent仅负责展示逻辑，核心业务逻辑全部放在独立服务类中，既保持了Razor Pages的页面简洁性，又实现了表单逻辑的完全解耦。

方案2：模块化MVC（选MVC时的优化方案） #

• 将每个表单封装成独立模块，用MVC的Areas来组织，每个Area对应一个表单（或一类表单），包含专属的Controller、Model、View。
• 路由统一规划为/Forms/[FormType]/Submit、/Forms/[FormType]/Approve，每个表单的Controller独立处理自身的提交、审批、查看逻辑，后期新增表单只需添加新的Area模块，维护性极强。

方案3：Razor Pages + 页面模型继承 #

• 定义抽象基类BaseFormPageModel，封装通用逻辑（如权限校验、队列处理基础流程）。
• 每个表单创建对应的页面模型子类（如FormOrderPageModel : BaseFormPageModel），实现自身专属的提交、审批方法。
• 通过路由参数动态匹配对应的Razor Page（如/Forms/Submit/{FormType}），这种方式保留了Razor Pages的特性，同时让每个表单的逻辑独立拆分，适合表单逻辑差异较大的场景。

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