.NET 6开发TodoList应用之使用MediatR实现POST请求

目录
  • 需求
  • 目标
  • 原理与思路
    • CQRS模式
    • 中介者Mediator模式
    • MediatR
  • 实现
    • 引入MediatR
    • 实现Post请求
  • 验证
    • 创建TodoList验证
    • 创建TodoItem验证
  • 总结
  • 参考资料

需求

需求很简单:如何创建新的TodoList和TodoItem并持久化。

初学者按照教程去实现的话,应该分成以下几步:创建Controller并实现POST方法;实用传入的请求参数new一个数据库实体对象;调用IRepository<T>完成数据库的写入,最多会在中间加一层Service。这个做法本身没有问题,也是需要从初学阶段开始扎实地掌握开发技能的必经之路,有助于帮助理解逻辑调用的过程。

对于稍微正式一些的项目,.NET工程上习惯的实现是通过使用一些比较成熟的类库框架,有效地对业务逻辑进行分类管理、消除冗余代码,以达到业务逻辑职责清晰简洁的目的。在这个阶段我们经常使用的两个类库分别是AutoMapper和MediatR,本文结合POST请求,先介绍关于MediatR部分,下一篇关于GET请求,会涉及AutoMapper的部分。

目标

合理组织并使用MediatR,完成POST请求。

原理与思路

首先来简单地介绍一下这个类库。

关于CQRS模式、中介者模式和MediatR

CQRS模式

CQRS模式全称是“Command Query Responsibility Segregation”,正如字面意思,CQRS模式的目的在于将读取操作和写入操作的指责区分开,并使用不同的Model去表示。从CRUD的角度来说,就是把R和CUD区分开来对待。如下图所示:

这个模式可以有效地应用到具有主从分离的数据库架构中,当需要获取数据时,从只读数据库(一般是从库)中读取数据,当需要写入或更新数据时,向主库进行操作。

CQRS模式旨在解决的问题是:为了屏蔽数据库层面“写优先”还是“读优先”的优化设计策略,在业务逻辑侧进行解耦。

任何设计模式都是对解决特定问题的一个Trade off,自然也带来了一些缺点,首先就是服务内部的组件复杂度上升了,因为需要创建额外的类来实现CQRS模式;其次如果数据层是分离的,那么可能会有数据的状态不一致问题。

中介者Mediator模式

这是23种基本设计模式中的一个,属于行为型设计模式,它给出了组件之间交互的一种解耦的方式。简单参考下图,具体内容就不过多解释了,任何一篇介绍设计模式的文章都有介绍。

这种设计模式实际上是一种采用依赖倒置(Inversion of Control, IoC)的方式,实现了图中蓝色组件的松耦合。

MediatR

这是在开发中被广泛采用的实现以上两种设计模式的类库,更准确的说法是,它通过应用中介者模式,实现了进程内CQRS。基本思想是所有来自API接口和数据存储之间的逻辑,都需要通过MediatR来组织(即所谓的“中介者”)。

从实现上看,MediatR提供了几组用于不同场景的接口,我们在本文中处理的比较多的是IRequest<T>/IRequestHandler<T>以及INotification<T>/INotificationHander<T>两组接口,更多的请参考官方文档和例子。

实现

所有需要使用MediatR的地方都集中在Application项目中。

引入MediatR

$ dotnet add src/TodoList.Application/TodoList.Application.csproj package MediatR.Extensions.Microsoft.DependencyInjection

为了适配CQRS的模式,我们在Application项目中的TodoLists和TodoItems下相同地创建几个文件夹:

Commands:用于组织CUD相关的业务逻辑;

Queries:用于组织R相关的业务逻辑;

EventHandlers:用于组织领域事件处理的相关业务逻辑。

在Application根目录下同样创建DependencyInjection.cs用于该项目的依赖注入:

DependencyInjection.cs

using System.Reflection;

using Microsoft.Extensions.DependencyInjection;

namespace TodoList.Application;

public static class DependencyInjection

{

    public static IServiceCollection AddApplication(this IServiceCollection services)

    {

        services.AddMediatR(Assembly.GetExecutingAssembly());

        return services;

    }

}

并在Api项目中使用:

// 省略其他...
// 添加应用层配置
builder.Services.AddApplication();
// 添加基础设施配置
builder.Services.AddInfrastructure(builder.Configuration);

实现Post请求

在本章中我们只实现TodoList和TodoItem的Create接口(POST),剩下的接口后面的文章中逐步涉及。

POST TodoList

在Application/TodoLists/Commands/下新建一个目录CreateTodoList用于存放创建一个TodoList相关的所有逻辑:

CreateTodoListCommand.cs

using MediatR;

using TodoList.Application.Common.Interfaces;

namespace TodoList.Application.TodoLists.Commands.CreateTodoList;

public class CreateTodoListCommand : IRequest<Guid>

{

    public string? Title { get; set; }

}

public class CreateTodoListCommandHandler : IRequestHandler<CreateTodoListCommand, Guid>

{

    private readonly IRepository<Domain.Entities.TodoList> _repository;

    public CreateTodoListCommandHandler(IRepository<Domain.Entities.TodoList> repository)

    {

        _repository = repository;

    }

    public async Task<Guid> Handle(CreateTodoListCommand request, CancellationToken cancellationToken)

    {

        var entity = new Domain.Entities.TodoList

        {

            Title = request.Title

        };

        await _repository.AddAsync(entity, cancellationToken);

        return entity.Id;

    }

}

有一些实践是将Request和RequestHandler分开两个文件,我更倾向于像这样将他俩放在一起,一是保持简洁,二是当你需要顺着一个Command去寻找它对应的Handler时,不需要更多的跳转。

接下来在TodoListController里实现对应的POST方法,

using MediatR;

using Microsoft.AspNetCore.Mvc;

using TodoList.Application.TodoLists.Commands.CreateTodoList;

namespace TodoList.Api.Controllers;

[ApiController]

[Route("/todo-list")]

public class TodoListController : ControllerBase

{

    private readonly IMediator _mediator;

    // 注入MediatR

    public TodoListController(IMediator mediator)

        => _mediator = mediator;

    [HttpPost]

    public async Task<Guid> Create([FromBody] CreateTodoListCommand command)

    {

        var createdTodoList = await _mediator.Send(command);

        // 出于演示的目的,这里只返回创建出来的TodoList的Id,

        // 实际使用中可能会选择IActionResult作为返回的类型并返回CreatedAtRoute对象,

        // 因为我们还没有去写GET方法,返回CreatedAtRoute会报错(找不到对应的Route),等讲完GET后会在那里更新

        return createdTodoList.Id;

    }

}

POST TodoItem

类似TodoListController和CreateTodoListCommand的实现,这里我直接把代码贴出来了。

CreateTodoItemCommand.cs

using MediatR;

using TodoList.Application.Common.Interfaces;

using TodoList.Domain.Entities;

using TodoList.Domain.Events;

namespace TodoList.Application.TodoItems.Commands.CreateTodoItem;

public class CreateTodoItemCommand : IRequest<Guid>

{

    public Guid ListId { get; set; }

    public string? Title { get; set; }

}

public class CreateTodoItemCommandHandler : IRequestHandler<CreateTodoItemCommand, Guid>

{

    private readonly IRepository<TodoItem> _repository;

    public CreateTodoItemCommandHandler(IRepository<TodoItem> repository)

    {

        _repository = repository;

    }

    public async Task<Guid> Handle(CreateTodoItemCommand request, CancellationToken cancellationToken)

    {

        var entity = new TodoItem

        {

            // 这个ListId在前文中的代码里漏掉了,需要添加到Domain.Entities.TodoItem实体上

            ListId = request.ListId,

            Title = request.Title,

            Done = false

        };

        await _repository.AddAsync(entity, cancellationToken);

        return entity.Id;

    }

}

TodoItemController.cs

using MediatR;

using Microsoft.AspNetCore.Mvc;

using TodoList.Application.TodoItems.Commands.CreateTodoItem;

namespace TodoList.Api.Controllers;

[ApiController]

[Route("/todo-item")]

public class TodoItemController : ControllerBase

{

    private readonly IMediator _mediator;

    // 注入MediatR

    public TodoItemController(IMediator mediator) 

        => _mediator = mediator;

    [HttpPost]

    public async Task<Guid> Create([FromBody] CreateTodoItemCommand command)

    {

        var createdTodoItem = await _mediator.Send(command);

        // 处于演示的目的,这里只返回创建出来的TodoItem的Id,理由同前

        return createdTodoItem.Id;

    }

}

验证

运行Api项目,通过Hoppscotch发送对应接口请求:

创建TodoList验证

请求

返回

数据库

第一条数据是种子数据,第二条是我们刚才创建的。

创建TodoItem验证

继续拿刚才创建的这个TodoList的Id来创建新的TodoItem:

请求

返回

数据库

最后一条是我们新创建的,其余是种子数据。

总结

我们已经通过演示在POST请求中实现MediatR库带来的CQRS模式,在这篇文章里我留了一个坑。就是领域事件的Handler并没有任何演示,只是创建了一个文件夹,结合在这篇文章中留下来的发布领域事件的坑,会在DELETE的文章中填完。

看起来使用CQRS模式使得我们的代码结构变得更加复杂了,但是对于一些再复杂一些的实际项目中,正确使用CQRS模式有助于你分析和整理业务需求,并将相关的业务需求以及相关模型梳理到统一的位置进行管理,包括在后续的文章里我们会陆续向其中加入诸如入参校验、出参类型转换等逻辑。认真思考并运用习惯之后,大家可以自行体会这样做的“权衡”。

参考资料

MediatR

Mediator 

以上就是.NET 6开发TodoList应用之使用MediatR实现POST请求的详细内容,更多关于.NET 6 MediatR实现POST请求的资料请关注我们其它相关文章!

(0)

相关推荐

  • .NET 6开发TodoList应用引入数据存储

    目录 一.需求 二.目标 三.原理和思路 四.实现 1. 引入Nuget包并进行配置 2. 添加DBContext对象并进行配置# 3. 配置文件修改 4. 主程序配置 5. 本地运行MSSQL Server容器及数据持久化 五.验证 一.需求 作为后端CRUD程序员(bushi,数据存储是开发后端服务一个非常重要的组件.对我们的TodoList项目来说,自然也需要配置数据存储. 目前的需求很简单: 需要能持久化TodoList对象并对其进行操作: 需要能持久化TodoItem对象并对其进行操作

  • .NET 6开发TodoList应用引入第三方日志库

    目录 1.需求 2.目标 3.原理和思路 4.实现 4.1日志配置实现 4.2主程序配置 4.3注入使用 5.验证 1.需求 在我们项目开发的过程中,使用.NET 6自带的日志系统有时是不能满足实际需求的,比如有的时候我们需要将日志输出到第三方平台上,最典型的应用就是在各种云平台上,为了集中管理日志和查询日志,通常会选择对应平台的日志SDK进行集成.使用Serilog提供的多种Sink,可以实现将日志写入不同云平台或者是非云平台的日志存储中去,这是我们这篇文章讲要研究的内容. 2.目标 我们将为

  • .NET 6开发TodoList应用实现系列背景

    目录 1.列说明 2.系列导航 2.1 使用.NET 6开发TodoList应用文章索引 2.1.1创建项目 2.1.2.NET 6 WebAPI Program.cs的变更 2.1.3Change 1: Top-level statements 2.1.4Change 2: Implicit using directives 2.1.5Change 3: No Startup class 2.2 关于Pipeline的一些知识点 2.2.1Pipeline Sequence 2.2.2app.

  • .NET 6开发TodoList应用实现结构搭建

    目录 1.TodoList需求简介 2.开发工具 2.1.NET 6 2.2Visual Studio Code 2.3Hoppscotch 3.Clean Architecture简介 4.搭建解决方案结构 5.运行 往期学习: .NET 6开发TodoList应用实现系列背景 1.TodoList需求简介 首先明确一下我们即将开发的这个TodoList应用都需要完成什么功能,我不会一次性把所有的特性诸如允许用户登陆之类的需求全部写上,只是先列出最基本的功能性需求: 我们可以维护一个TodoL

  • 使用.NET 6开发TodoList应用之领域实体创建原理和思路

    需求 上一篇文章中我们完成了数据存储服务的接入,从这一篇开始将正式进入业务逻辑部分的开发. 首先要定义和解决的问题是,根据TodoList项目的需求,我们应该设计怎样的数据实体,如何去进行操作? 长文预警!包含大量代码 目标 在本文中,我们希望达到以下几个目标: 定义领域实体: 通过数据库操作领域实体: 原理和思路 虽然TodoList是一个很简单的应用,业务逻辑并不复杂,至少在这个系列文章中我并不想使其过度复杂.但是我还是打算借此简单地涉及领域驱动开发(DDD)的基础概念. 首先比较明确的是,

  • .NET 6开发TodoList应用之使用MediatR实现POST请求

    目录 需求 目标 原理与思路 CQRS模式 中介者Mediator模式 MediatR 实现 引入MediatR 实现Post请求 验证 创建TodoList验证 创建TodoItem验证 总结 参考资料 需求 需求很简单:如何创建新的TodoList和TodoItem并持久化. 初学者按照教程去实现的话,应该分成以下几步:创建Controller并实现POST方法:实用传入的请求参数new一个数据库实体对象:调用IRepository<T>完成数据库的写入,最多会在中间加一层Service.

  • .NET 6开发TodoList应用之使用AutoMapper实现GET请求

    目录 需求 目标 原理与思路 实现 引入AutoMapper 实现GET请求 验证 获取所有TodoList列表 获取单个TodoList详情 填一个POST文章里的坑 总结 需求 需求很简单:实现GET请求获取业务数据.在这个阶段我们经常使用的类库是AutoMapper. 目标 合理组织并使用AutoMapper,完成GET请求. 原理与思路 首先来简单地介绍一下这这个类库. 关于AutoMapper 在业务侧代码和数据库实体打交道的过程中,一个必不可少的部分就是返回的数据类型转换.对于不同的

  • .NET 6开发TodoList应用之实现PUT请求

    目录 需求 目标 原理与思路 实现 PUT请求 领域事件的发布和响应 验证 总结 需求 PUT请求本身其实可说的并不多,过程也和创建基本类似.在这篇文章中,重点是填上之前文章里留的一个坑,我们曾经给TodoItem定义过一个标记完成的领域事件:TodoItemCompletedEvent,在SaveChangesAsync方法里做了一个DispatchEvents的操作.并且在DomainEventService实现IDomainEventService的Publish方法中暂时以下面的代码代替

  • .NET 6开发TodoList应用之实现DELETE请求与HTTP请求幂等性

    目录 需求 目标 原理与思路 实现 验证 总结 需求 先说明一下关于原本想要去更新的PATCH请求的文章,从目前试验的情况来看,如果是按照.NET 6的项目结构(即只使用一个Program.cs完成程序初始化),那微软官方给出的文档目前还没有对应地更新,按照之前的方式进行JsonPatch的配置是不行的,目前已经有人在Github微软的官方文档Repo下提了ISSUE: .NET 6: JsonPatch in ASP.NET Core web API.并且因为PATCH的使用频率并不高,所以我

  • .NET 6开发TodoList应用之实现查询分页

    目录 需求 目标 原理与思路 实现 定义分页结果数据结构 添加对于分页结果的Mapping Profile 创建分页查询请求 创建查询Controller 验证 总结 需求 查询中有个非常常见的需求就是后端分页,实现的方式也不算复杂,所以我们本文仅仅演示一个后端查询分页的例子. 目标 实现分页查询返回. 原理与思路 对于分页查询而言,我们需要在请求中获取当前请求的是第几页,每页请求多少项数据.在返回值中需要告诉前端,当前这一页的所有数据项列表,总共的数据项有多少.为此我们可以定义一个包装类型,供

  • .NET 6开发TodoList应用之实现ActionFilter

    目录 需求 目标 原理与思路 实现 验证 总结 需求 Filter在.NET Web API项目开发中也是很重要的一个概念,它运行在执行MVC响应的Pipeline中执行,允许我们将一些可以在多个Action之间重用的逻辑抽取出来集中管理.虽然我们在上一篇使用.NET 6开发TodoList应用之实现接口请求验证中演示了如何通过使用MediatR提供的IPipelineBehavior接口在CQRS的Handle方法执行前后插入可重用代码,而本文所演示的Filters作用在Controller的

  • .NET 6开发TodoList应用之实现接口请求验证

    目录 需求 目标 原理与思路 实现 验证 一点扩展 总结 参考资料 需求 在响应请求处理的过程中,我们经常需要对请求参数的合法性进行校验,如果参数不合法,将不继续进行业务逻辑的处理.我们当然可以将每个接口的参数校验逻辑写到对应的Handle方法中,但是更好的做法是借助MediatR提供的特性,将这部分与实际业务逻辑无关的代码整理到单独的地方进行管理. 为了实现这个需求,我们需要结合FluentValidation和MediatR提供的特性. 目标 将请求的参数校验逻辑从CQRS的Handler中

  • .NET 6开发TodoList应用之实现查询排序

    目录 需求 目标 原理与思路 实现 验证 总结 需求 关于查询的另一个需求是要根据前端请求的排序字段进行对结果相应的排序. 目标 实现根据排序要求返回排序后的结果 原理与思路 要实现根据前端请求的进行相应排序,结合我们之前写好的Specification,可以比较简单地做到. 实现 我们还是用TodoItem请求来举例,再添加一个排序字段到查询请求中: GetTodoItemsWithConditionQuery.cs using AutoMapper; using AutoMapper.Que

  • .NET 6开发TodoList应用之实现数据塑形

    目录 需求 目标 原理与思路 实现 定义通用接口和泛型类实现 定义扩展方法 添加依赖注入 修改查询请求和Controller接口 验证 总结 需求 在查询的场景中,还有一类需求不是很常见,就是在前端请求中指定返回的字段,所以关于搜索的最后一个主题我们就来演示一下关于数据塑形(Data Shaping). 目标 实现数据塑形搜索请求. 原理与思路 对于数据塑形来说,我们需要定义一些接口和泛型类实现来完成通用的功能,然后修改对应的查询请求,实现具体的功能. 实现 定义通用接口和泛型类实现 IData

  • 使用.NET 6开发TodoList应用之引入数据存储的思路详解

    需求 作为后端CRUD程序员(bushi,数据存储是开发后端服务一个非常重要的组件.对我们的TodoList项目来说,自然也需要配置数据存储.目前的需求很简单: 需要能持久化TodoList对象并对其进行操作: 需要能持久化TodoItem对象并对其进行操作: 问题是,我们打算如何存储数据? 存储组件的选择非常多:以MSSQL Server/Postgres/MySql/SQLite等为代表的关系型数据库,以MongoDB/ElasticSearch等为代表的非关系型数据库,除此之外,我们还可以

随机推荐