示例工程【免费下载链接】practical-aspnetcorePractical samples of ASP.NET Core 11, 10, 9, 8.0, 7.0, 6.0, 5.0, 3.1, 2.2, and 2.1,projects you can use. Readme contains explanations on all projects.项目地址https://gitcode.com/gh_mirrors/pr/practical-aspnetcore点击查看免费下载导读本文围绕 practical-aspnetcore 仓库中的 new-routing-2 示例讲解如何在 ASP.NET Core 应用中只启用 MVC 路由且仅使用属性路由Attribute Routing而非约定路由Convention Routing。通过阅读本文你将掌握AddControllersWithViews()与MapControllers()的组合用法、属性路由与约定路由的本质区别以及禁用 Razor Pages、仅保留 MVC的轻量级应用组织方式。示例要解决的问题在 ASP.NET Core 3.0 引入端点路由Endpoint Routing之后应用的端点Endpoint不再由框架一刀切地统一注册而是由开发者按需组织。new-routing-2 是 endpoint-routing 系列示例 中的一员它的目标非常明确只启用MVC路由只使用属性路由通过[Route]、[HttpGet]等特性声明不使用约定路由如{controller}/{action}模板Razor Pages 在该示例中完全不可用。整个示例只有 14 行核心代码Program.cs是理解 MVC 端点注册最小形态的最佳切入点。完整源码与逐行解读示例的核心代码位于 Program.csusing Microsoft.AspNetCore.Mvc; var builder WebApplication.CreateBuilder(); builder.Services.AddControllersWithViews(); var app builder.Build(); app.MapControllers(); app.Run(); [Route()] public class HomeController : Controller { public IActionResult Index() Content(Hello World. Razor Pages wont work in this sample.); }第一步注册 MVC 服务builder.Services.AddControllersWithViews();AddControllersWithViews()向依赖注入容器注册 MVC 所需的全部服务包括控制器、视图引擎Razor Views与模型绑定等。注意它只注册 MVC不注册 Razor Pages——这就是Razor Pages 完全不可用的根本原因。要启用 Razor Pages必须另行调用AddRazorPages()参见同目录下 new-routing 示例 的builder.Services.AddRazorPages()。第二步映射带属性路由的控制器app.MapControllers();MapControllers()是IEndpointRouteBuilder的扩展方法作用是把所有使用属性路由的控制器 Action注册为应用端点。它是 MVC 属性路由Attribute Routing的端点注册入口控制器或 Action 上声明了[Route]、[HttpGet]、[HttpPost]等特性就会被MapControllers()收集并注册它不会注册任何约定路由——约定路由需要额外调用MapControllerRoute()或MapDefaultControllerRoute()显式声明对比 new-routing-3 示例 中的app.MapDefaultControllerRoute()。原 README 中描述为使用app.UseRouting启用这是 ASP.NET Core 3.0 时代的写法UseRouting()UseEndpoints(e e.MapControllers())。在 current 仓库使用的最小托管模型Minimal Hosting中app.MapControllers()直接挂在IEndpointRouteBuilder上路由中间件由WebApplication在管线执行时自动处理因此源码中无需显式调用UseRouting()。第三步声明属性路由的控制器[Route()] public class HomeController : Controller { public IActionResult Index() Content(Hello World. Razor Pages wont work in this sample.); }HomeController在类级别标注[Route()]即把控制器绑定到根路径/。IndexAction 没有额外标注 HTTP 动词特性因此匹配所有 HTTP 动词的/请求并返回一段纯文本内容Hello World. Razor Pages wont work in this sample.。这里展示了一个重要的端点路由特性端点Endpoint由路由中间件从EndpointDataSource中选取。MapControllers()内部注册的正是 MVC 的ControllerActionEndpointDataSource它会扫描所有带属性路由特性的控制器 Action 生成端点请求到达后由路由中间件匹配并执行。这与约定路由Convention Routing在端点生成机制上是两套独立的路径。属性路由 vs 约定路由两个关键区别new-routing-2 的核心价值在于它只启用属性路由。它与约定路由的区别可以概括为两点维度属性路由Attribute Routing约定路由Convention Routing路由声明位置控制器/Action 上的[Route]、[HttpGet]等特性全局路由模板如{controller}/{action}/{id?}注册方式app.MapControllers()app.MapControllerRoute(...)或app.MapDefaultControllerRoute()路由与控制器的耦合路由随代码声明就近查看路由集中在启动代码全局生效适用场景Web API、模块化、路由需要精细控制传统 MVC 站点、约定统一的页面导航仓库中两个示例的对比可以直观印证这一区别new-routing-2MapControllers()[Route()]只有属性路由new-routing-3MapDefaultControllerRoute()启用默认约定路由{controllerHome}/{actionIndex}/{id?}此时即使控制器没有[Route]特性/Home/Index也能命中。如果需要注册多条约定路由可以参考 new-routing-20 示例其中使用MapControllerRoute分别声明了Admin、About与默认路由三条模板。与仓库中相近示例的横向对比endpoint-routing 目录下存在一组服务注册与端点映射变体示例放在一起看能更清楚每个 API 的边界示例服务注册端点映射能力范围new-routingAddRazorPages()MapRazorPages()仅 Razor Pagesnew-routing-2AddControllersWithViews()MapControllers()仅 MVC 属性路由new-routing-3AddControllersWithViews()MapDefaultControllerRoute()MVC 默认约定路由new-routing-17AddControllers()MapControllers()仅 MVC无 Views适合 Web APInew-routing-18AddControllersWithViews()MapControllers()仅 MVC含 Views无 Razor Pages其中new-routing-2 与 new-routing-18 的端点映射完全相同都是MapControllers()区别仅在服务注册层面new-routing-18 同样调用AddControllersWithViews()。而 new-routing-17 使用AddControllers()去掉 Views 支持是纯 Web API 形态——这组对比清晰地说明服务注册决定能力范围端点映射决定路由形态二者是正交的两个关注点。为什么Razor Pages 不会工作从仓库源码可以推断出结论链条AddControllersWithViews()只向容器注册 MVC 相关服务没有调用AddRazorPages()因此 Razor Pages 的端点数据源PageRouteModelProvider 等根本没有被注册MapControllers()只注册控制器的属性路由端点不执行MapRazorPages()因此应用内不存在任何 Razor Pages 端点访问.cshtml页面路由自然 404。这正是示例输出 Razor Pages wont work in this sample. 所传达的事实。运行与验证项目配置new-routing-2.csproj 采用Microsoft.NET.Sdk.WebSDK目标框架为net10.0开启ImplicitUsings语言版本为preview与仓库根目录 global.json 指定的 .NET SDK10.0.0一致允许预发布版本回滚。运行步骤# 方式一从仓库根目录指定项目运行 dotnet run --project projects/endpoint-routing/new-routing-2 # 方式二进入项目目录后运行 cd projects/endpoint-routing/new-routing-2 dotnet run应用启动后访问根路径/按控制台输出的监听地址为准未配置 launchSettings.json 时 Kestrel 默认监听 HTTP 地址浏览器或 curl 将返回Hello World. Razor Pages wont work in this sample.此时访问任何 Razor Pages 路径例如/Index或/Privacy都会得到 404因为应用根本没有注册 Razor Pages 端点。构建验证仓库提供了批量构建脚本new-routing-2 已纳入其中在 projects/endpoint-routing/build.sh 中可以看到dotnet build new-routing-2条目对应 projects/build.sh 的整体构建流程。也可以单独执行dotnet build projects/endpoint-routing/new-routing-2源码级理解MapControllers 与端点数据源从端点路由的设计角度看MapControllers()的调用链可以概括为app.MapControllers() → 向 IEndpointRouteBuilder 的 DataSources 集合 追加 ControllerActionEndpointDataSource → 端点路由中间件运行时遍历 DataSources 依据属性路由模板 约束匹配当前请求以上为从仓库示例代码结构推断的实现路径具体内部实现以 .NET 运行时源码为准。这意味着 MVC 的属性路由在端点路由体系中被数据源化了路由规则不再是启动时一次性生成的中间件分支而是与 Razor Pages、Minimal APIMapGet/MapPost等、健康检查MapHealthChecks统一为EndpointDataSource上的端点集合由同一个路由中间件负责匹配。这也是 new-routing-2 这类只映射一种端点示例的深层意义——开发者可以精确控制应用中存在哪些端点这正是端点路由相比传统UseMvc()的核心优势。适用场景与小结当你的应用满足以下特征时可以借鉴 new-routing-2 的形态以 MVC 控制器承载业务逻辑但不需要 Razor Pages页面由前端 SPA、静态文件或其他技术栈渲染路由需要贴近代码声明属性路由便于模块化开发与单文件可读性希望最小化端点暴露面只注册需要的路由避免约定路由带来的隐式端点。需要提醒的是如果应用仍需要约定路由例如传统 MVC 站点依赖{controller}/{action}统一导航则应改用MapDefaultControllerRoute()或MapControllerRoute()参考 new-routing-3 与 new-routing-20如果同时需要 Razor Pages则需补充AddRazorPages()与MapRazorPages()参考 new-routing。总而言之new-routing-2 用最小代码演示了只启用 MVC 属性路由的完整可行方案服务注册用AddControllersWithViews()划定能力边界端点映射用MapControllers()声明路由形态。理解这两步的分工就能在端点路由框架下随心所欲地组织自己的应用端点。赞分享示例工程【免费下载链接】practical-aspnetcorePractical samples of ASP.NET Core 11, 10, 9, 8.0, 7.0, 6.0, 5.0, 3.1, 2.2, and 2.1,projects you can use. Readme contains explanations on all projects.项目地址https://gitcode.com/gh_mirrors/pr/practical-aspnetcore点击查看免费下载相关推荐practical-aspnetcore 端点路由实战用 MapDefaultControllerRoute 只启用 MVC 与默认约定路由practical aspnetcore 端点路由实战用 MapDefaultControllerRoute 只启用 MVC 与默认约定路由 本文基于 pra示例工程LeakCanary for Releases在发布版 App 中做生产环境堆内存泄漏检测的完整实战指南LeakCanary for Releases在发布版 App 中做生产环境堆内存泄漏检测的完整实战指南 LeakCanary 不仅能在 debug 构建中检示例工程Open Higgsfield AI架构深度剖析从组件设计到Muapi.ai API集成原理Open Higgsfield AI架构深度剖析从组件设计到Muapi.ai API集成原理 Open Higgsfield AI是一款强大的AI应用它不仅AI 应用媒体生成大模型创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?