WPF vs ASP.NET Core

关键架构差异

WPF 应用程序通常由 App.xaml 定义入口，并在 App.xaml.cs 的 OnStartup 方法中执行初始化逻辑。开发者习惯于在此处实例化主窗口（MainWindow），并可能初始化一个 MVVM 框架（如 Prism 的 Bootstrapper）来配置依赖注入容器 。

ASP.NET Core 采用了通用主机（Generic Host）模式，其入口点位于 Program.cs。这个文件承担了两个截然不同的职责阶段：服务注册（Service Registration） 和 请求管道配置（Pipeline Configuration）

依赖注入 (Dependency Injection)

• WPF: 你可能用过 Prism 或 MVVMToolkit 来做 DI，或者手动 new 对象。
• ASP.NET Core: DI 是二等公民，更是“呼吸”。框架强制你使用 DI。所有的 Service（数据库上下文、日志、业务逻辑）都在 Program.cs 中注册，然后在构造函数中注入。

中间件管道 (Middleware Pipeline)

这是 ASP.NET Core 的心脏。

• WPF: 事件路由（冒泡/隧道）。
• ASP.NET Core: 管道模型。一个请求进来，像水流一样经过一个个“滤网”（中间件）。
  • 滤网1： 也是异常处理吗？
  • 滤网2： 是身份验证吗？
  • 滤网3： 是具体的业务逻辑（Controller）吗？

WPF 程序员最容易踩的坑（注意事项）

1. 静态变量是危险的：在 WPF 里，static 变量可以存全局状态。在 Web Server 里，静态变量被所有用户的请求共享。如果你存了 “CurrentUser”，那甲用户登录后，乙用户也会看到甲的名字。
   • 解决： Web 是无状态的，用户信息通常存在 Token 或 Session 中，随每次请求传来。
   • WPF 是长生命周期的有状态模型，内存变量可直接跨交互保留状态；ASP.NET Core 是瞬时请求的无状态模型，单次请求结束后上下文即销毁，跨请求状态需外部存储
2. 不要阻塞主线程？：在 WPF 中，await 是为了不卡死 UI。在 ASP.NET Core 中，await 是为了释放线程去处理其他人的请求。如果你的 API 阻塞了（不用 async），服务器吞吐量会急剧下降。
3. Scoped 生命周期：这是 Web 特有的。
   • Transient: 每次注入都 new 一个新的（轻量级）。
   • Singleton: 全局单例（类似 WPF 的全局服务）。
   • Scoped: 关键点。一次 HTTP 请求内共享同一个实例，请求结束就释放。数据库连接（DbContext）通常是 Scoped。

思想转变

范围验证与依赖捕获 (Captive Dependency)

WPF 开发者在迁移时最常犯的错误之一是“依赖捕获”。在桌面应用中，由于缺乏请求作用域的概念，开发者可能习惯将所有服务注册为单例。但在 ASP.NET Core 中，如果一个 Singleton 服务在其构造函数中注入了一个 Scoped 服务（例如 DbContext），那么这个 Scoped 服务将永远不会被释放，因为它被 Singleton 服务持有了。这会导致数据库连接池耗尽、内存泄漏以及数据陈旧问题。

ASP.NET Core 在开发环境下默认开启了 ValidateScopes 检查，会在启动时抛出异常来阻止这种错误配置。WPF 开发者必须理解，DbContext 设计为短生命周期对象，必须在 Scoped 服务或 Controller 中使用，绝不能在 Singleton 中直接使用

替代 Prism/Unity 的内置容器

许多 WPF 开发者习惯使用 Unity 或 Autofac 等第三方容器。ASP.NET Core 内置的 Microsoft.Extensions.DependencyInjection 虽然功能相对精简（不支持属性注入，仅支持构造函数注入），但性能极高且足以满足 99% 的需求。

• 构造函数注入 (Constructor Injection)：这是 ASP.NET Core 的标准模式。所有依赖项必须在构造函数中声明。
• 方法注入 (Method Injection)：仅在极少数场景（如 Controller Action 或 Middleware Invoke）中使用 ``。
• 属性注入 (Property Injection)：内置容器不支持，这与某些 WPF 框架的习惯不同，需强制改为构造函数注入。

请求处理管道与中间件

洋葱模型 (The Onion Model)

• WPF 的事件系统基于可视树（Visual Tree）的路由事件（Routed Events），分为隧道（Tunneling, Preview事件）和冒泡（Bubbling, 标准事件）。
• ASP.NET Core 的中间件管道采用了类似的“洋葱模型”或“俄罗斯套娃模型”。 当 HTTP 请求到达服务器时，它通过注册的中间件链条层层深入。每个中间件都有机会在请求处理 之前 和 之后 执行逻辑。

1
2
3
4
5
6
7
8
9
10
11
12

// 模拟中间件逻辑
public async Task InvokeAsync(HttpContext context, RequestDelegate next)
{
    // 1. 请求进入阶段 (Inbound) - 类似于 WPF 的 Preview 事件 (Tunneling)
    Console.WriteLine("Request Start");
    
    // 调用下一个中间件
    await next(context);
    
    // 2. 响应返回阶段 (Outbound) - 类似于 WPF 的冒泡事件 (Bubbling)
    Console.WriteLine("Response End");
}

异常处理的差异

• 在 WPF 中，开发者依赖 Application.DispatcherUnhandledException 来捕获 UI 线程未处理的异常，防止程序崩溃 。
• 在 ASP.NET Core 中，异常处理是通过 中间件 实现的。UseExceptionHandler 中间件通常配置在管道的最外层。当后续的 Controller 或 Service 抛出异常时，异常会沿着管道回传（Unwind），直到被 ExceptionHandler 捕获并转换为标准的 HTTP 500 错误页面或 JSON 响应 。

关键洞察： WPF 的全局异常处理往往是为了“吞掉”错误让程序继续运行（虽然不推荐），但在 Web API 中，异常处理的核心目标是将.NET 异常转换为标准化的 HTTP 协议响应（如 RFC 7807 Problem Details），并确保不在响应中泄露敏感的堆栈信息（Security by Default）。

WPF 布局控件与 CSS 对应关系

建议： 不要试图用 HTML <table> 模拟 WPF 的 Grid。WPF 开发者应学习 Tailwind CSS 或 Bootstrap。例如，WPF 的 <StackPanel Orientation="Horizontal"> 在 Tailwind 中只需写 <div class="flex flex-row gap-4">，这种实用主义 CSS 框架能极大地降低 XAML 开发者的学习曲线

快速入门

启动流程

ASP.NET Core 采用了通用主机（Generic Host）模式，其入口点位于 Program.cs。这个文件承担了两个截然不同的职责阶段：服务注册（Service Registration） 和 请求管道配置（Pipeline Configuration）

服务注册阶段 (The Builder Phase)

在 var builder = WebApplication.CreateBuilder(args); 之后，开发者必须显式注册所有依赖项。这与 WPF 中某些“按需实例化”或隐式依赖的习惯不同。ASP.NET Core 强制要求所有服务（包括数据库上下文、业务逻辑服务、MVC 框架服务等）在应用构建之前完成注册。这类似于 WPF Prism 框架中 RegisterTypes 的过程，但在 ASP.NET Core 中，这是框架运行的基石，而非可选组件

管道配置阶段 (The App Phase)

在 var app = builder.Build(); 之后，代码进入了中间件管道的配置。这部分代码定义了 HTTP 请求如何被处理。这在 WPF 中没有直接对应物，最接近的概念可能是 WPF 的事件路由（Routed Events）中的“隧道（Tunneling）”和“冒泡（Bubbling）”机制，但中间件是线性的、双向的流处理模型

ASP.NET Core (Program.cs) - 声明式构建与管道

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

var builder = WebApplication.CreateBuilder(args);

// 1. 服务注册 (Services) - 对应 WPF 的 IOC 容器配置
// 这一步必须在 Build() 之前完成，不允许后续动态添加
builder.Services.AddControllersWithViews();
builder.Services.AddScoped<IProductService, ProductService>(); // 生命周期管理核心
builder.Services.AddDbContext<AppDbContext>(options =>...);

var app = builder.Build();

// 2. 管道配置 (Middleware) - 定义请求处理流
// 类似于定义事件处理链，但应用于所有 HTTP 请求
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error"); // 全局异常捕获
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles(); // 允许访问 wwwroot 下的 CSS/JS
app.UseRouting(); // 路由匹配
app.UseAuthorization(); // 安全鉴权

// 3. 端点映射 (Endpoints) - 将 URL 映射到代码逻辑
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run(); // 启动 Kestrel 服务器监听端口

ASP.NET Core 的启动过程更加结构化和声明式。WPF 开发者需要从“编写过程式启动代码”转向“配置依赖和服务拓扑”

一个简单的API(Controller)

在 WPF 中，你写 ViewModel 处理命令；在 Web API 中，你写 Controller 处理请求

创建一个 WeatherController.cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

using Microsoft.AspNetCore.Mvc;

[ApiController] // 标记这是一个 API 控制器
[Route("[controller]")] // 路由规则：访问 /Weather 就能找到这个类
public class WeatherController : ControllerBase
{
    // 模拟的数据服务（在 WPF 中你可能作为属性注入到 VM）
    private readonly ILogger<WeatherController> _logger;

    // 构造函数注入 (DI)
    public WeatherController(ILogger<WeatherController> logger)
    {
        _logger = logger;
    }

    // 对应 HTTP GET 请求
    // 类似于 WPF 的 ICommand Execute 方法
    [HttpGet(Name = "GetWeatherForecast")]
    public IEnumerable<string> Get()
    {
        // 这里的返回值会被自动序列化成 JSON 发送给客户端
        return new List<string> { "Sunny", "Cloudy", "Rainy" };
    }
}

转exe

如果想让ASP.NET Core 服务能双击启动（类似 exe），不需要用 Docker，直接把项目 发布为 “自包含部署包”即可：

1. 在 VS 中右键项目→发布；
2. 选择 “文件夹” 作为发布目标；
3. 在 “发布配置文件设置” 中，选择：
   • 部署模式：自包含；
   • 目标运行时：win-x64（对应 Windows 64 位系统）；
4. 点击 “发布”，完成后会生成一个包含.NET 运行时的文件夹；
5. 文件夹里的项目名.exe就是可双击启动的服务程序，启动后自动运行 Kestrel 服务器。

环境相关

dotnet6.0迁移到dotnet8.0

下载安装.NET8 SDK

可以并存

VS安装时勾选必选工作负载：「ASP.NET和 Web 开发」（自动包含.NET 8 相关组件）；

前端选型

wpf的绑定,在ASP.NET+vue中如何实现