MVC的路由规则配置方式比较多，咱们用得最多的是两种： A、全局规则。就是我们熟悉的”{controller}/{action}“。 app.MapControllerRoute( name: "bug", pattern: "{controller}/{action}" ); app.MapCon
IActionHttpMethodProvider 接口的结构很简单，实现该接口只要实现一个属性即可——HttpMethods。该属性是一个字符串序列。 这啥意思呢？这个字符串序列代表的就是受支持的 HTTP 请求方式。比如，如果此属性返回 GET POST，那么被修饰的对象既支持 HTTP-GET
咱们都知道，MVC在输入/输出中都需要模型绑定。因为HTTP请求发送的都是文本，为了使其能变成各种.NET 类型，于是在填充参数值之前需 ModelBinder 的参与，以将文本转换为 .NET 类型。 尽管 ASP.NET Core 已内置基础类型和复杂类型的各种 Binder，但有些数据还是不能
验证和授权是两个独立但又存在联系的过程。验证是检查访问者的合法性，授权是校验访问者有没有权限查看资源。它们之间的联系——先验证再授权。 贯穿这两过程的是叫 Claim 的东东，可以叫它“声明”。没什么神秘的，就是由两个字符串组成的对象，一曰 type，一曰 value。type 和 value 有着
上次老周和大伙伴们分享了有关按用户Level授权的技巧，本文咱们聊聊以用户角色来授权的事。 按用户角色授权其实更好弄，毕竟这个功能是内部集成的，多数场景下我们不需要扩展，不用自己写处理代码。从功能语义上说，授权分为按角色授权和按策略授权，而从代码本质上说，角色权授其实是包含在策略授权内的。怎么说呢？
在开始之前，老周先祝各个次元的伙伴们新春快乐、生活愉快、万事如意。 在上一篇水文中，老周介绍了角色授权的一些内容。本篇咱们来聊一个比较实际的问题——把用于授权的角色名称放到外部配置，不要硬编码，以方便后期修改。 由于要配置的东西比较简单，咱们并不需要存在数据库，而是用 JSON 文件配置就可以了。将
ASP.NET Core 中的几大功能模块（Razor Pages、MVC、SignalR/Blazor、Mini-API 等等）都以终结点（End Point）的方式公开。在HTTP管道上调用时，其扩展方法基本是以 Map 开头，如 MapControllers、MapBlazorHub。 对于
标记帮助器，即 Tag Helpers。这个嘛，就直接翻译了，叫“标记帮助器”，虽然不好听，但只能这样了。当然你翻译为“标记增强器”也行。 所谓标记帮助器，就是针对 HTML 标签（不管是标准的还是自己命名的）进行扩展的做法。它是以 Razor 为基础的，服务于开发人员的。在服务器端用 C# 代码来
前一篇中老周从标记帮助的底层介绍关键性的接口，如 ITagHelper ，它是一个标志，用于识别哪些类属于 Tag Helper。 标记帮助器毕竟是针对 HTML 标记的，所以得筛选。说白了就是我写的这个帮助器在哪些 HTML 标记上起作用。这就需要拿出一个特性类。 [AttributeUsage(
标记帮助器不仅可以给目标元素（标记）插入（或修改）属性，插入自定义的HTML内容，在某些需求中还可以替换原来标记的名称。 比如我们在使用 Blazor 时很熟悉的 Component 标记帮助器。在 Razor 文档中你将使用 元素来设置要呈现的组件。而在实际处理时，会去掉
Blazor Server，即运行在服务器上的 Blazor 应用程序，它的优点是应用程序在首次运行时，客户端不需要下载运行时。但它的代码是在服务器上执行的，然后通过 SignalR 通信来更新客户端的 UI，所以它要求必须建立 Web Socket 连接。 用于 Blazor 应用的 Signal
由于 Blazor-WebAssembly 是在浏览器中运行的，通常不需要执行服务器代码，只要有个“窝”能托管并提供相关文件的下载即可。所以，当你有一个现成的 Blazor wasm 项目，没必要用其他语言重写，或者你不想用 ASP.NET Core 来托管（有些大材小用了），就可以试试用 node
## 一、什么是SignalR： **SignalR** 是用于构建需要实时用户交互或实时数据更新的Web 应用程序的一个开放源代码.NET 库。不仅仅用在Web应用中，后面会讲到它的应用范围。它简化了简化了构建实时应用程序的过程，包括**ASP.NET Server**库和**JavaScript
.Net Core 跨域
前言 C# 编码规范中，类和属性都是大写驼峰命名风格（PascalCase / UpperCamelCase），而在数据库中我们往往使用小写蛇形命名（snake_case），在默认情况下，EFCore会把原始的类名和属性名直接映射到数据库，这不符合数据库的命名规范。 为了符合命名规范，而且也为了看起
前言 很多项目一开始选型的时候没有选择EFCore，不过EFCore确实好用，也许由于种种原因后面还是需要用到，这时候引入EFCore也很方便。 本文以 StarBlog 为例，StarBlog 目前使用的 ORM 是 FreeSQL ，引入 EFCore 对我来说最大的好处是支持多个数据库，如果是
最近，在使用MongoDB时，碰到这样的一个需求：针对某个Collection手动在开发环境创建了索引，但在测试环境和生产环境不想再手动操作了，于是就想着干脆通过代码的方式在ASP.NET 6应用启动时自动创建，如果是重复创建则直接跳过。
经过版本更新，Mini API 的功能逐步完善，早期支持得不太好的 mini API 现在许多特性都可以用了，比如灰常重要的依赖注入。 咱们先来个相当简单的注入测试。来，定义一个服务类，为了偷懒，老周这里就不使用 接口 + 实现类 的方式了。 public class MyService : IDi
前言 最近一直在忙（2月份沉迷steam，3月开始工作各种忙），好久没更新博客了，不过也积累了一些，忙里偷闲记录一下。 这个需求是这样的，我之前做了个工单系统，现在要对登录、注册、发起工单这些功能做限流，不能让用户请求太频繁。 从 .Net7 开始，已经有内置的限流功能了，但目前我们的项目还在使用
## 前言 对于Web API应用程序而言，随着时间的推移以及需求的增加或改变，API必然会遇到升级的需求。事实上，Web API应用程序应该从创建时就考虑到API版本的问题。业务的调整、功能的增加、接口的移除与改名、接口参数变动、实体属性的添加、删除和更改等都会改变API的功能，从而带来版本的变更
