ASP.NET Core 主机模型详解:Host、WebHost与WebApplication的对比与实践【代码之美】

ASP.NET Core 主机模型详解:Host、WebHost与WebApplication的对比与实践【代码之美】

🎀🎀🎀代码之美系列目录🎀🎀🎀

一、C# 命名规则规范
二、C# 代码约定规范
三、C# 参数类型约束
四、浅析 B/S 应用程序体系结构原则
五、浅析 C# Async 和 Await
六、浅析 ASP.NET Core SignalR 双工通信
七、浅析 ASP.NET Core 和 MongoDB 创建 Web API
八、浅析 ASP.NET Web UI 框架 Razor Pages/MVC/Web API/Blazor
九、如何使用 MiniProfiler WebAPI 分析工具
十、浅析 .NET Core 中各种 Filter
十一、C#.Net筑基-类型系统
十二、C#.Net 筑基-运算符
十三、C#.Net筑基-解密委托与事件
十四、C#.Net筑基-集合知识大全
十五、C#.Net筑基 - 常见类型
十六、C#.NET体系图文概述—2024最全总结
十七、C# 强大无匹的模式匹配,让代码更加优雅
十八、C# 中的记录类型简介
十九、C# 异步编程模型【代码之美系列】
二十、C#高级篇 反射和属性详解【代码之美系列】
二十一、.NET Core 中获取各种路径的的方法汇总【代码之美】
二十二、【C#实战】动态模板替换:根据Model字段名称自动匹配替换值【代码之美】
二十三、.NET 集成 Velocity 模板引擎实现动态代码生成(高性能+易扩展)
二十四、在 .NET 8/9 中使用 AppUser 进行 JWT 令牌身份验证
二十五、.NET8 中间件与过滤器的对比:深入解析与应用场景
二十六、.NET Core 中获取各种路径的的方法汇总【代码之美】
二十七、.NET 8 实现大文件分片上传:本地存储解决方案【代码之美】

文章目录


前言

ASP.NET Core开发中,主机(Host)是应用程序的入口和运行环境。随着版本的迭代,ASP.NET Core提供了不同的主机模型,包括 HostWebHostWebApplication。许多开发者对这些概念容易混淆,本文将深入解析它们的区别,并通过实际代码演示各自的用法。

一、主机模型概述

1.1 主机的作用

主机在 ASP.NET Core 中负责:

  • 应用程序的启动和生命周期管理
  • 依赖注入容器的配置
  • 应用程序配置的设置
  • 日志系统的初始化
  • 中间件管道的构建(针对Web应用)

1.2 三种主机的演进

  • WebHost (1.0-3.x):最初的Web应用主机
  • Host (3.0+):通用主机,用于 非HTTP 场景
  • WebApplication (6.0+):现代化 Web应用 主机

二、三种主机的详细对比

2.1 WebHost (传统Web主机)

publicclassProgram{publicstaticvoidMain(string[] args){CreateWebHostBuilder(args).Build().Run();}publicstaticIWebHostBuilderCreateWebHostBuilder(string[] args)=> WebHost.CreateDefaultBuilder(args).ConfigureAppConfiguration((hostingContext, config)=>{// 配置设置}).ConfigureLogging(logging =>{// 日志配置}).UseStartup<Startup>();}

🎯关键点:

  • 使用 WebHost.CreateDefaultBuilder创建
  • 需要 Startup 类分离配置
  • 🚫在ASP.NET Core 3.0+中已过时

2.2 Host (通用主机)

publicclassProgram{publicstaticvoidMain(string[] args){CreateHostBuilder(args).Build().Run();}publicstaticIHostBuilderCreateHostBuilder(string[] args)=> Host.CreateDefaultBuilder(args).ConfigureServices((hostContext, services)=>{ services.AddHostedService<Worker>();});}publicclassWorker:BackgroundService{protectedoverrideasyncTaskExecuteAsync(CancellationToken stoppingToken){// 后台服务逻辑}}

🎯关键点:

  • 使用 Host.CreateDefaultBuilder 创建
  • 适合后台服务、控制台应用等 非HTTP 场景
  • 不包含Web 服务器

2.3 WebApplication (现代Web主机)

var builder = WebApplication.CreateBuilder(args);// 添加服务到容器 builder.Services.AddControllers(); builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen();var app = builder.Build();// 配置HTTP请求管道if(app.Environment.IsDevelopment()){ app.UseSwagger(); app.UseSwaggerUI();} app.UseHttpsRedirection(); app.UseAuthorization(); app.MapControllers(); app.Run();

🎯关键点:

  • 使用 WebApplication.CreateBuilder 创建
  • 更简洁的API设计
  • 支持最小API
  • 推荐用于 ASP.NET Core 6.0+ 的新项目

三、最佳实践与迁移建议

3.1 如何选择主机模型

场景推荐主机
新Web项目 (6.0+)WebApplication
旧Web项目 (3.0-5.0)WebHost (考虑迁移)
后台服务/WorkerHost

3.2 从WebHost迁移到WebApplication

旧代码 (WebHost):

publicclassStartup{publicvoidConfigureServices(IServiceCollection services){ services.AddControllers();}publicvoidConfigure(IApplicationBuilder app){ app.UseRouting(); app.UseEndpoints(endpoints => endpoints.MapControllers());}}

新代码 (WebApplication):

var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllers();var app = builder.Build(); app.MapControllers(); app.Run();

3.3 最小API示例

var builder = WebApplication.CreateBuilder(args);var app = builder.Build(); app.MapGet("/",()=>"Hello World!"); app.MapGet("/user/{id}",(int id)=>$"User ID: {id}"); app.Run();

四、常见问题解答

Q1:WebApplication和Host能否共存?

A:可以,WebApplication 内部实际上使用了 Host 作为基础,并添加了 Web 特定功能。

Q2:何时需要使用单独的Startup类?

A:在 WebApplication 模型中,Startup 类不再是必需的,所有配置可以在Program.cs` 中完成。但大型项目仍可分离配置。

Q3:性能上有差异吗?

A:WebApplication 启动更快,因为减少了间接层,但运行时性能差异不大。

结语

理解 ASP.NET Core 的不同主机模型对于构建高效应用程序至关重要。随着.NET的演进,WebApplication 已成为最简单、最直接的 Web 应用构建方式。✅建议新项目直接采用 WebApplication 模型,现有项目可考虑逐步迁移。

Read more

前端存储三剑客:localStorage、sessionStorage、cookie 超详细对比

前端存储三剑客:localStorage、sessionStorage、cookie 超详细对比

在前端开发中,数据本地存储是提升用户体验、优化性能、实现持久化状态的核心技术。我们最常用的就是 localStorage、sessionStorage 和 cookie 这三种方案,但很多开发者容易混淆它们的用法、存储特性和适用场景。 这篇博客就用最清晰、最实用的方式,一次性讲透三者的区别、用法和最佳实践。 一、先搞懂核心概念 * cookie:最早的客户端存储方案,会随 HTTP 请求自动发送到服务器,主要用于身份验证、会话保持。 * localStorage:HTML5 新增的本地存储,持久化存储,手动清除才会消失,不参与网络请求。 * sessionStorage:HTML5 新增的会话存储,页面会话期间有效,关闭标签页 / 浏览器就清空。 二、核心区别一张表看懂 表格 特性localStoragesessionStoragecookie生命周期永久有效,手动清除仅当前会话(关闭标签 / 浏览器失效)可设置过期时间,默认会话级存储容量约 5MB约 5MB很小,仅 4KB与服务端通信不参与不参与自动携带在

高德地图JSAPI加载器实战指南:从零构建Web地图应用

1. 为什么你需要一个靠谱的地图加载器? 如果你正在开发一个需要展示地理位置信息的网站或应用,比如找附近的餐厅、显示物流轨迹、或者做一个房产地图找房系统,那你大概率绕不开地图服务。国内开发者最常用的就是高德地图,它的数据全、更新快,而且JSAPI用起来也挺顺手。但说实话,我第一次用的时候,直接在HTML里用<script>标签引入官方CDN链接,虽然简单,问题却不少。 页面加载慢不说,有时候网络一波动,地图就加载失败了,用户体验很糟糕。更麻烦的是管理依赖和版本,项目稍微复杂点,多个地方用到地图,版本不一致或者重复加载,能让人调试到头疼。后来我发现了@amap/amap-jsapi-loader这个官方出的加载器,用上之后感觉整个世界都清净了。它本质上是一个帮你更优雅、更可靠地加载高德地图JavaScript API的工具包,特别适合用在像Vue、React这样的现代前端项目里。它能帮你处理异步加载、错误重试、版本管理这些脏活累活,让你能更专注于地图业务逻辑的开发。 简单来说,这个加载器就像是一个专业的“地图服务生”。你不用自己跑去厨房(高德服务器)端菜(JS文件),也不用担心端来

AnythingtoRealCharacters2511企业应用案例:ACG内容平台真人化素材自动化生产

AnythingtoRealCharacters2511企业应用案例:ACG内容平台真人化素材自动化生产 1. 引言:当动漫角色走进现实 想象一下,你是一家ACG(动画、漫画、游戏)内容平台的运营负责人。每天,你的团队需要为海量的动漫IP制作宣传海报、社交媒体配图、视频封面。传统的做法是找画师重新绘制真人风格的同人图,或者用真人模特进行拍摄,但前者风格不稳定,后者成本高昂且难以还原角色神韵。 现在,情况正在改变。基于Qwen-Image-Edit模型开发的AnythingtoRealCharacters2511镜像,正在为内容创作领域带来一场效率革命。这个工具的核心能力很简单,却极具颠覆性:将任何动漫、游戏角色图片,一键转化为高质量的真人风格图像。 对于内容平台而言,这意味着什么?意味着你可以将已有的动漫素材库,快速、批量地转化为符合真人审美、适合更广泛受众传播的视觉内容。无论是为《原神》的角色制作一组“如果他们在现实世界”的写真,还是将经典日漫人物转化为适合品牌联动的代言人形象,这个过程从过去需要数天甚至数周的创意与执行,缩短到了几分钟。 本文将深入探讨Anythingt

1Panel面板下Open WebUI镜像加速实战:从ghcr.io到国内镜像站的无缝切换

1. 为什么需要镜像加速 在国内使用Docker拉取GitHub Container Registry(ghcr.io)的镜像时,经常会遇到下载速度极慢甚至完全无法连接的问题。这主要是因为ghcr.io的服务器位于海外,国内访问存在网络延迟和带宽限制。以Open WebUI为例,一个3GB左右的镜像可能需要数小时才能下载完成,严重影响开发效率。 我曾经在部署Open WebUI时就遇到过这个问题。当时尝试从ghcr.io直接拉取镜像,速度只有几十KB/s,而且经常中断。后来发现国内高校和云服务商提供了ghcr.io的镜像服务,切换到南京大学镜像源后,下载速度立刻提升到10MB/s以上,整个镜像几分钟就完成了下载。 2. 国内镜像站的选择 目前国内可用的ghcr.io镜像站主要有以下几种: 1. 南京大学镜像站(ghcr.nju.edu.cn):这是最稳定的选择之一,更新频率高,支持匿名拉取 2. 华为云镜像仓库(swr.cn-north-4.myhuaweicloud.com):提供企业级镜像服务,需要登录后使用