系列导航及源代码 使用.NET 6开发TodoList应用文章索引 需求 本文我们继续来看查询过程中的另外一个需求:搜索.搜索的含义是目标字段的全部或者部分值匹配请求中的搜索条件,对应到数据库层面是Contains逻辑.实现起来也很简单. 目标 实现包含搜索条件的查询. 原理与思路 实现搜索的方式和之前基本思路是一致的,这篇文章大概是这个系列到目前为止最直接和简单的了. 实现 直接修改上一篇里定义的GetTodoItemsWithConditionQuery,添加一个Title字段用于搜索: G…

系列导航及源代码 使用.NET 6开发TodoList应用文章索引 需求 查询中有个非常常见的需求就是后端分页,实现的方式也不算复杂,所以我们本文仅仅演示一个后端查询分页的例子. 目标 实现分页查询返回. 原理与思路 对于分页查询而言,我们需要在请求中获取当前请求的是第几页,每页请求多少项数据.在返回值中需要告诉前端,当前这一页的所有数据项列表,总共的数据项有多少.为此我们可以定义一个包装类型,供系统中所有需要提供后端分页查询返回值使用. 除了最基本的实现方式之外,我们可能还需要实现关于分页数据…

系列导航及源代码 使用.NET 6开发TodoList应用文章索引 需求 在查询请求中,还有一类常见的场景是过滤查询,也就是有限制条件的查询,落在数据库层面就是常用的Where查询子句.实现起来也很简单. 目标 实现查询过滤的功能 原理与思路 查询过滤的请求有两种方式,一种是采用POST方法,将查询条件放在请求体中,但是这种方式实际上和Restful的动词语义产生了矛盾,从Restful API成熟度模型的角度来说,还停留在Level 1阶段(仅知道地址,不符合动词语义),详情参考理查森成熟度模…

系列导航及源代码 使用.NET 6开发TodoList应用文章索引 需求 关于查询的另一个需求是要根据前端请求的排序字段进行对结果相应的排序. 目标 实现根据排序要求返回排序后的结果 原理与思路 要实现根据前端请求的进行相应排序,结合我们之前写好的Specification,可以比较简单地做到. 实现 我们还是用TodoItem请求来举例,再添加一个排序字段到查询请求中: GetTodoItemsWithConditionQuery.cs using AutoMapper; using Auto…

需求 在我们项目开发的过程中,使用.NET 6自带的日志系统有时是不能满足实际需求的,比如有的时候我们需要将日志输出到第三方平台上,最典型的应用就是在各种云平台上,为了集中管理日志和查询日志,通常会选择对应平台的日志SDK进行集成.比如微软Azure提供的Azure App Service Logging,基础的用法可以参考这篇文章:ASP.NET Core Logging with Azure App Service and Serilog.同时在这篇文章中也提到了使用Serilog提供的多种…

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

为了不影响阅读的体验,我把系列导航放到文章最后了,有需要的小伙伴可以直接通过导航跳转到对应的文章 : P TodoList需求简介 首先明确一下我们即将开发的这个TodoList应用都需要完成什么功能,我不会一次性把所有的特性诸如允许用户登陆之类的需求全部写上,只是先列出最基本的功能性需求: 我们可以维护一个TodoList. TodoList可以包含多个TodoItem. 对于TodoList,我们可以设置其名称 对于每个TodoItem,我们可以设置其内容,超期时间,是否完成. 对于所有实体…

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

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

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