.net6

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，可以实现将日志写入不同云平台或者是非云平台的日志存储中去，这是我们这篇文章讲要研究的内容。

首先明确一下我们即将开发的这个TodoList应用都需要完成什么功能，我不会一次性把所有的特性诸如允许用户登陆之类的需求全部写上，只是先列出最基本的功能性需求

想到要写这样一个系列博客，初衷有两个：一是希望通过一个实践项目，将.NET 6 WebAPI开发的基础知识串联起来，帮助那些想要入门.NET 6服务端开发的朋友们快速上手，对使用.NET 6开发后端服务的技术全貌有一个基本的认识和掌握，顺便把自己的技能树检查一遍；二是希望为国内的.NET环境有一些小小的帮助，最早我自己是做C#桌面应用出身的，但是随着互联网产业的繁盛和微软早年间的固执，使得国内的.NET开发环境收缩到几个固定的领域，以致于很多人今天依然认为C#和.NET不适合做大型的企业级应用，这个观念需要改变了。

项目源码 TodoList on Github 系列导航