使用.NET 6开发TodoList应用(15)——实现查询搜索
系列导航及源代码 需求 本文我们继续来看查询过程中的另外一个需求:搜索。搜索的含义是目标字段的全部或 Read more…
系列导航及源代码 需求 本文我们继续来看查询过程中的另外一个需求:搜索。搜索的含义是目标字段的全部或 Read more…
系列导航及源代码 需求 在查询请求中,还有一类常见的场景是过滤查询,也就是有限制条件的查询,落在数据 Read more…
系列导航及源代码 需求 查询中有个非常常见的需求就是后端分页,实现的方式也不算复杂,所以我们本文仅仅 Read more…
在上篇演示Action Filter的时候可能是因为举的例子不够好,有小伙伴在评论区指出.NET 6新增加的特性可以实现在视图模型绑定之前允许记录Http请求日志的组件:HttpLogging。这个组件我之前试过,而Action Filter与其用来记录日志,更不如说是为Http请求的接收和响应提供了中间可以修改的机会。
Filter在.NET Web API项目开发中也是很重要的一个概念,它运行在执行MVC响应的Pipeline中执行,允许我们将一些可以在多个Action之间重用的逻辑抽取出来集中管理。虽然我们在上一篇使用.NET 6开发TodoList应用(11)——使用FluentValidation和MediatR实现接口请求验证中演示了如何通过使用MediatR提供的IPipelineBehavior接口在CQRS的Handle方法执行前后插入可重用代码,而本文所演示的Filters作用在Controller的Action执行或Action返回结果前后。
在响应请求处理的过程中,我们经常需要对请求参数的合法性进行校验,如果参数不合法,将不继续进行业务逻辑的处理。我们当然可以将每个接口的参数校验逻辑写到对应的Handle方法中,但是更好的做法是借助MediatR提供的特性,将这部分与实际业务逻辑无关的代码整理到单独的地方进行管理。
为了实现这个需求,我们需要结合FluentValidation和MediatR提供的特性。
系列导航及源代码 需求 先说明一下关于原本想要去更新的PATCH请求的文章,从目前试验的情况来看,如 Read more…
系列导航及源代码 需求 PUT请求本身其实可说的并不多,过程也和创建基本类似。在这篇文章中,重点是填 Read more…
因为在项目中,会有各种各样的领域异常或系统异常被抛出来,那么在Controller里就需要进行完整的try-catch捕获,并根据是否有异常抛出重新包装返回值。这是一项机械且繁琐的工作。有没有办法让框架自己去做这件事呢
需求很简单:实现GET请求获取业务数据。在这个阶段我们经常使用的类库是AutoMapper。
对于稍微正式一些的项目,.NET工程上习惯的实现是通过使用一些比较成熟的类库框架,有效地对业务逻辑进行分类管理、消除冗余代码,以达到业务逻辑职责清晰简洁的目的。在这个阶段我们经常使用的两个类库分别是AutoMapper和MediatR,本文结合POST请求,先介绍关于MediatR部分,下一篇关于GET请求,会涉及AutoMapper的部分。
经常写CRUD程序的小伙伴们可能都经历过定义很多Repository接口,分别做对应的实现,依赖注入并使用的场景。有的时候会发现,很多分散的XXXXRepository的逻辑都是基本一致的,于是开始思考是否可以将这些操作抽象出去,当然是可以的,而且被抽象出去的部分是可以不加改变地在今后的任何有此需求的项目中直接引入使用。
作为后端CRUD程序员(bushi,数据存储是开发后端服务一个非常重要的组件。对我们的TodoList项目来说,自然也需要配置数据存储。
在我们项目开发的过程中,使用.NET 6自带的日志系统有时是不能满足实际需求的,比如有的时候我们需要将日志输出到第三方平台上,最典型的应用就是在各种云平台上,为了集中管理日志和查询日志,通常会选择对应平台的日志SDK进行集成。比如微软Azure提供的Azure App Service Logging,基础的用法可以参考这篇文章:ASP.NET Core Logging with Azure App Service and Serilog。同时在这篇文章中也提到了使用Serilog提供的多种Sink,可以实现将日志写入不同云平台或者是非云平台的日志存储中去,这是我们这篇文章讲要研究的内容。