在我们团队的开发历程中,C# 和 .NET 框架一直是我们的主力语言,伴随我们走过了无数个项目。当微软推出 Blazor 这一革命性的框架时,我们对其充满了期待。Blazor 以其优良的架构和微软的强大背书,似乎预示着前端开发的新纪元。我们希望借助 Blazor 的优势,快速构建与后台服务配套的前端应用。然而,随着开发的深入,我们发现这条路并不如预期顺利,最终不得不放弃 Blazor,转而使用其他 Web 技术。本文将分享我们的经历,希望能为其他团队提供参考。
1. 初识 Blazor 全栈 UI:满怀期待
Blazor 的出现,让我们看到了使用 C# 进行前端开发的可能性。对于习惯了 .NET 环境的开发者来说,这无疑是个好消息。我们可以在不切换语言的情况下,编写前端代码,提升了开发效率和代码一致性。
Blazor 全栈 UI 的技术架构优势明显:
- 统一的开发体验:开发者可以使用相同的 C# 代码和 Razor 组件在 Blazor Server 和 Blazor WebAssembly 之间进行无缝切换,简化了多种应用类型的开发流程。
- 灵活的应用架构:Blazor Web App 可以根据具体需求灵活选择 Blazor Server 或 Blazor WebAssembly。
- Blazor Server 通过 SignalR 技术提供服务端和客户端的实时数据传输,和较快的初始加载时间。
- 而 Blazor WebAssembly 可以在浏览器中高效运行,允许用户离线使用,减少服务器负担,提高用户的交互体验。
- 支持灵活地选择 Server 还是 WASM 进行渲染,可以针对整个应用程序、某个页面或控件设置渲染模式。
- 可以将 Server 搭建为 Backend-for-Frontend,写后台接口访问数据库。WASM 搭建为 Frontend,编写布局和页面。达到前后端分离,前端的页面元素渲染和交互不再依赖后端,只有调用 API 获取数据需要后端。
- 增强的性能:.NET 8 中的 Blazor 具有更好的性能优化,包括更快的组件渲染和数据传输,提升了用户体验。通过加强导航(Enhanced Navigation)功能,使用户在交互和导航时感觉在浏览 SPA 网站。
- 利用渲染树构建组件:提供了 ChildContent、ChildFragment 来灵活地自定义控件元素的样式和行为,支持通过模板重写控件内部的元素。
- 用户身份和权限认证:利用 Identity 无缝便捷地集成用户验证和权限控制,支持对某个页面、控件、Controller,API 设置访问权限。WASM 应用缓存了属于客户端的数据,无需在服务端维护,例如用户身份信息、登录状态等等。
- 熟悉的开发工具:Visual Studio 和其他 IDE 对 Blazor Web App 的友好支持,提供更好的调试体验和开发效率。
2. 遭遇挑战:理想与现实的差距
然而,理想很丰满,现实却很骨感。在项目推进过程中,我们逐渐感受到 Blazor 的局限性。以下是我们遇到的一些主要问题:
- UI 组件库有限:相比于 React、Vue 等成熟框架,虽然 Blazor 社区在不断发展,但现有的 UI 组件库仍然相对较少。并且,面对某些复杂的前端效果,我们发现 Blazor 难以将不同组件库中的组件融合在一起使用,库之间很难做到样式和操作的统一,这严重影响了我们的开发效率。
- 前端效果难以实现:Blazor 在处理某些前端效果时显得力不从心。由于其运行机制的特殊性,一些在其他框架中轻松实现的动画、交互效果,在 Blazor 中却需要绕过各种限制,利用 JS 互操作来完成。这不仅降低了开发效率,也影响了用户体验。
- 社区支持不足:一个框架的生态环境对于其发展至关重要。我们发现,当遇到问题时,几乎无法在社区中找到解决方案。一些无法通过官方文档解决的疑问,StackOverflow 或 GitHub 上的相关帖子寥寥无几。这使得我们在排查和解决问题时陷入困境。
3. 展望未来:Blazor 的前景并不明朗
- 缺乏实际应用案例:尽管 Blazor 在技术上有许多优点并受到微软的支持,但目前为止,使用 Blazor 搭建网站的知名企业、公司或组织仍然相对稀少。这使得潜在用户对其稳定性和长期可维护性产生疑虑。
- 微软的转向:更让人担忧的是,微软似乎不再为 Blazor 投入足够的资源。近年来,微软的重心逐渐转移到人工智能(AI)领域,对 Blazor 的更新和支持力度明显下降。这让 Blazor 的未来充满了不确定性。
4. 做出抉择:从 Blazor 回到 Vue
经过一段时间的开发,我们团队意识到,Blazor 可能并不适合我们未来的产品路线。尽管我们喜欢用 C# 开发,但在 Web 开发领域,其他技术栈在组件丰富性、社区支持和生态系统上显然更具优势。
综合以上因素,我们不得不做出艰难的决定:
- 停止在新产品中使用 Blazor:为了项目的长期发展,我们决定在下一个产品中放弃使用 Blazor。
- 重构现有产品的前端部分:对于已经使用 Blazor 的产品,我们计划在第二个版本中重构前端,改用更成熟的 Web 技术,如 Vue。
这一决策虽然艰难,但也是我们经过深思熟虑后的选择。
5. 反思与建议:Blazor 的适用场景
通过这次经历,我们发现选用 Blazor 可以从以下几点因素去考量:
- 团队规模:Blazor 更适合单兵作战的开发者,或 2 至 4 人的小团队。这些开发者通常具有较强的 C# 和 .NET 背景,能够快速上手,学习 Blazor 的负担相对其他非 .NET 背景的开发者要小很多,可以利用现有的 .NET 技能快速构建和部署小型项目。
- 应用类型:Blazor 非常适合用于构建功能相对简单的标准管理系统,比如内部管理工具,进行数据录入、生成报告、利用仪表盘和报表进行数据展示。这些应用通常不需要复杂的前端交互,且需求相对稳定,可以利用 Blazor 的组件化特性快速搭建。
- 产品演化:Blazor 更适合那些在开发初期对功能和用户界面需求有明确设定的产品。这种情况下,可以在产品发布后无需过多的担心产品后期的接手和维护问题。减少产品变更和迭代所带来的维护成本。
6. 结语
在这个快速发展的技术世界里,选择一个合适的开发框架至关重要。Blazor 的理念值得肯定,但在当前阶段,可能还不适合用于大型商业项目。我们的经验教训也提醒着其他团队,在技术选择上要更加谨慎和前瞻。
未来,我们仍会关注 Blazor 的发展,但在那之前,我们将选择更适合当前需求的技术方案。尽管我们与 Blazor 的旅程暂告一段落,但这段经历将成为我们继续探索和学习的宝贵财富。
Disclaimer 声明:本文由 AI 辅助完成撰写