.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.Run和app.Use
      • 2.2.3app.Map和app.MapWhen

前言:

想到要写这样一个系列博客,初衷有两个:一是希望通过一个实践项目,将.NET 6 WebAPI开发的基础知识串联起来,帮助那些想要入门.NET 6服务端开发的朋友们快速上手,对使用.NET 6开发后端服务的技术全貌有一个基本的认识和掌握,顺便把自己的技能树检查一遍;二是希望为国内的.NET环境有一些小小的帮助,最早我自己是做C#桌面应用出身的,但是随着互联网产业的繁盛和微软早年间的固执,使得国内的.NET开发环境收缩到几个固定的领域,以致于很多人今天依然认为C#和.NET不适合做大型的企业级应用,这个观念需要改变了。我无意比较技术和语言之间的好坏,只是更愿意看到国内的技术环境也能呈现出百家争鸣的状态。经过微软这么多年的改变和进步,.NET 6是一个很优秀的框架,这一点自从我最开始接触.NET Core 2起一年一年进化到现在,就深切地感受到,那好东西就拿出来和大家分享一下。

1.列说明

在这个系列博客中,我将会使用.NET 6从头开始一步一步开发一个TodoList单体应用,在这个过程中尽可能将多的知识点独立成每篇文章,最后将应用通过Docker进行打包,并使用GithubActionAzure Container Instance服务实现CI/CD。

选择TodoList的原因是这个项目足够简单,但是也足够去覆盖我希望覆盖到的知识点,对于读者来说,有以下一些建议的前置要求:

  • 需要会写C#,不需要.NET (Core)相关的开发经验。
  • 需要后端服务的开发经验,对基本的服务端相关特性有一定的认识。
  • 有对Clean Architecture的基本理解。

2.系列导航

2.1 使用.NET 6开发TodoList应用文章索引

附:.NET 6 Web API项目代码上的变化

2.1.1创建项目

mkdir ProjectName && cd ProjectName
dotnet new sln -n SampleApi
dotnet new project -f net6.0 -n SampleApi -o SampleApi
dotnet sln SampleApi.sln add SampleApi/SampleApi.csproj
dotnet restore
dotnet run -p SampleApi/SampleApi.csproj

2.1.2.NET 6 WebAPI Program.cs的变更

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
app.Run();

2.1.3Change 1: Top-level statements

顶级声明使得我们在编写Program类时可以不用再定义该类,省略Main函数定义,直接开始写方法体。编译器会在编译阶段为我们自动加上命名空间和相关定义。

2.1.4Change 2: Implicit using directives

隐式using指令是编译器根据项目类型,在编译阶段自动生成一个名为CompanyEmployees.GlobalUsings.g.cs的文件,

内容如下:

// <auto-generated/>
global using global::Microsoft.AspNetCore.Builder;
global using global::Microsoft.AspNetCore.Hosting;
global using global::Microsoft.AspNetCore.Http;
global using global::Microsoft.AspNetCore.Routing;
global using global::Microsoft.Extensions.Configuration;
global using global::Microsoft.Extensions.DependencyInjection;
global using global::Microsoft.Extensions.Hosting;
global using global::Microsoft.Extensions.Logging;
global using global::System;
global using global::System.Collections.Generic;
global using global::System.IO;
global using global::System.Linq;
global using global::System.Net.Http;
global using global::System.Net.Http.Json;
global using global::System.Threading;
global using global::System.Threading.Tasks;

也可以在CompanyEmployees.csproj工程配置文件中修改以下属性,禁用全局隐式using指令这一特性:

<!-- <ImplicitUsings>enable</ImplicitUsings> -->
<ImplicitUsings>disable</ImplicitUsings>

2.1.5Change 3: No Startup class

到了.NET 6,陪伴我们好几个版本至今的ConfigureServices and Configure方法终于消失了,取而代之的是这两部分的配置都集中在了Program.cs中。曾经写过.NET Core WebAPI的小伙伴不难看出来现在应该写在哪里。

对于一些大型项目来说,这两部分我们肯定不能就这样写在Program.cs里面,后面将会想办法把这两部分单独拆开进行配置。

当然,老版本的含有Startup.cs的项目在.NET 6下打开没有任何问题。

2.2 关于Pipeline的一些知识点

2.2.1Pipeline Sequence

  • ExceptionHandler
  • HSTS
  • HttpsRedirection
  • Static Files
  • Routing
  • CORS
  • Authentication
  • Authorization
  • Custom Middlewares
  • Endpoint Configuration

2.2.2app.Run和app.Use

app.Run用于终止Pipeline的链式调用并向客户端返回

public static void Run(this IApplicationBuilder app, RequestDelegate handler);
public delegate Task RequestDelegate(HttpContext context);

app.Use用于向Pipeline中插入一段逻辑作为链式调用的其中一个环节

public static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext,
Func<Task>, Task> middleware);

2.2.3app.Map和app.MapWhen

这两个方法都是用于在middleware的链式调用中进行分支Pipeline调用链处理。

public static IApplicationBuilder Map(this IApplicationBuilder app, PathString
pathMatch, Action<IApplicationBuilder> configuration)

public static IApplicationBuilder MapWhen(this IApplicationBuilder app,
Func<HttpContext, bool> predicate, Action<IApplicationBuilder> configuration)

app.MapGet、app.MapPost、app.MapPut、app.Delete、app.MapMethods

在.NET 6中一个新增的特性叫做Minimal APIs,允许应用程序以这种形式响应客户端的请求,在快速构建微服务应用的过程中十分好用,在这个系列里,因为构建的是一个单体应用,这部分知识点我打算放到第二个系列关于微服务开发实践中去,看有没有更合适的场景去展示。

到此这篇关于.NET 6开发TodoList应用实现系列背景的文章就介绍到这了,更多相关NET 6开发TodoList实现系列背景内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • .NET 6开发TodoList应用之实现全局异常处理

    目录 需求 目标 原理和思路 实现 验证 总结 参考资料 需求 因为在项目中,会有各种各样的领域异常或系统异常被抛出来,那么在Controller里就需要进行完整的try-catch捕获,并根据是否有异常抛出重新包装返回值.这是一项机械且繁琐的工作.有没有办法让框架自己去做这件事呢? 有的,解决方案的名称叫做全局异常处理,或者叫做如何让接口优雅地失败. 目标 我们希望将异常处理和消息返回放到框架中进行统一处理,摆脱Controller层的try-catch块. 原理和思路 一般而言用来实现全局异

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

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

  • .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应用之实现接口请求验证

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

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

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

  • .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.列说明 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应用之请求日志组件HttpLogging介绍

    背景 因为在上篇演示Action Filter的时候可能是因为举的例子不够好,有小伙伴在评论区指出.NET 6新增加的特性可以实现在视图模型绑定之前允许记录Http请求日志的组件:HttpLogging.这个组件我之前试过,而Action Filter与其用来记录日志,更不如说是为Http请求的接收和响应提供了中间可以修改的机会. 本着让更多的人了解新知识的出发点,这次我们临时把这个主题加进来. 什么是HttpLogging? HttpLogging 是 .NET 6 新加入的一个框架内置的中间

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

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

  • .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应用之使用AutoMapper实现GET请求

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

  • .NET 6开发TodoList应用之实现Repository模式

    目录 需求 目标 原理和思路 实现 通用Repository实现 引入使用 验证 总结 需求 经常写CRUD程序的小伙伴们可能都经历过定义很多Repository接口,分别做对应的实现,依赖注入并使用的场景.有的时候会发现,很多分散的XXXXRepository的逻辑都是基本一致的,于是开始思考是否可以将这些操作抽象出去,当然是可以的,而且被抽象出去的部分是可以不加改变地在今后的任何有此需求的项目中直接引入使用. 那么我们本文的需求就是:如何实现一个可重用的Repository模块. 长文预警,

随机推荐