大家好,我是码农刚子。前几天分享的文章:《ASP.NET Core Blazor简介和快速入门三(布局和路由)》下面,有朋友评论说:这blazor 感觉回到了asp 时代。

那么,为什么会有这种说法?回想一下ASP时代是什么时候,大家还有没有印象。我2019年出来工作,当时是做C/S开发ERP系统,做了一年多,后面又转了B/S开发,一直到现在。两中不同的开发模式,针对两个不同的实体行业:一个是混凝土搅拌站,一个是pcb工厂。不过都是开发ERP系统。
为什么会感觉blazor回到了asp时代?我们来看看两者的相似之处:
这种感觉主要应该源于 “服务端渲染” 模式的回归。- 以页面为中心的模型: 在经典 ASP (或 ASP.NET Web Forms) 中,你构建的是一个一个的页面(.asp 或 .aspx)。每个请求都对应一个具体的页面文件。Blazor 也有 .razor 页面和组件,在服务端模式下,导航到一个 URL 会请求服务器,服务器处理并渲染整个页面后返回。这种“往返于服务器”的体验很像老式的 Web 开发。
- 服务器持有状态: 在 Blazor Server 模式下,组件的状态(变量、数据)和 DOM 渲染逻辑都保存在服务器的内存中(在一个称为“电路”的实时 SignalR 连接里)。这与 ASP.NET Web Forms 的 ViewState 机制在“状态保存在服务器端”这一概念上有相似之处,虽然技术实现完全不同。
- C# 代码主导: 你主要使用 C# 来编写业务逻辑和 UI 逻辑,而不是 JavaScript。这让习惯了 C# 后端开发的开发者感到非常亲切和统一,就像当年用 VBScript/C# 在服务器端写逻辑一样。
- 较少的客户端/服务器分离感: 在传统的多页面应用中,前端和后端的界限比较模糊。Blazor Server 也给人这种感觉,因为你不需要专门去构建一个独立的 Web API,服务器端方法可以直接被前端调用(通过 SignalR)。
当然,它与“ASP时代”也是有根本不同的,Blazor是一种“螺旋式上升”。
为什么说这是一种“螺旋式上升”?尽管有上述相似之处,但 Blazor 绝非简单的“复古”,它是在现代 Web 技术栈上对过去理念的重新思考和进化。- 组件化与声明式UI: 这是最大的不同。经典 ASP 是命令式和基于字符串模板的。你需要用 <% %> 块在 HTML 中混编代码,然后手动控制输出。而 Blazor 是声明式和基于组件的。你通过组件(如 <MyTable Data="@items"/>)来构建 UI,当数据状态 (items) 改变时,UI 会自动更新。这是现代前端框架(React, Vue, Angular)的核心思想,Blazor 将其带入了 .NET 世界。
- 强大的数据绑定: Blazor 提供了灵活且强大的双向数据绑定(@bind),远比经典 ASP 的简单输出或 Web Forms 的复杂 ViewState 机制要清晰和高效。
- 现代化的实时通信: Blazor Server 使用 SignalR 在客户端和服务器之间建立持久化的 WebSocket 连接。这使得 UI 更新是增量式的、实时的,体验非常流畅。而经典 ASP 是纯粹的“请求-响应”模型,每次交互都需要完整的页面回发和刷新,体验不可同日而语。
- 清晰的架构选择:
- Blazor Server: 类似于“复古”模式,但底层技术是现代、高效的。
- Blazor WebAssembly: 这是完全不同的模式,C# 代码直接在浏览器中运行,可以构建真正的单页面应用,完全脱离了“回到服务器”的感觉。这更像是一个用 C# 编写的 React/Vue 应用。
- 拥抱 Web 标准: Blazor 最终编译和运行在现代浏览器标准之上(WebAssembly 或通过 SignalR)。它不依赖像 Web Forms 那样笨重的、封装了 HTML 的服务器控件。
结语
Blazor Server 模式确实在开发体验上让人重温了服务端渲染的便捷和高效,特别是对于后端开发者来说,用 C# 搞定一切非常爽。但这绝不是简单的倒退,而是‘螺旋式上升’。
它保留了服务端开发的高生产率和对后端资源直接访问的优点,但同时融入了现代前端框架的‘组件化’和‘声明式UI’等先进理念。而且,你还有 Blazor WebAssembly 这个选项,可以让你用同样的技术栈构建完全在客户端运行的单页面应用。所以,它更像是取二者之精华,为 .NET 开发者提供了一条通往现代 Web 开发的全新路径。
简单来说,我认为 Blazor 降低 .NET 开发者进入现代 Web 开发门槛——它让熟悉服务器端思维的人能够平滑过渡,同时又赋予了他们构建现代化、交互式 Web 应用的能力。