Overview

在前面的文章里有针对 abp 的项目模板进行简化，构建了一个精简的项目模板，在使用过程中，因为我们暴露的 api 需要包含版本信息，我们采取的方式是将 api 的版本号包含在资源的 URI 中。因为 abp 默认的 api 是没有版本的概念的，所以这里为了实现 api 版本化需要针对 abp 项目的 api 路由进行改造，从而满足我们的需求。本篇文章则是实现这一改造过程的演示说明，希望可以对你有所帮助

完整的项目模板如下所示

模板源码地址：https://github.com/danvic712/ingos-abp-api-template

Overview

不管是公司或者个人都会有不同的开发习惯，通过建立项目模板，既可以使开发人员聚焦于业务功能的开发，也可以在一定程度上统一不同开发人员之间的开发风格。在使用 ABP 框架的过程中，对于 ABP 生成的默认项目模板，类库多，附加功能多，是目前在部门内部推行 ABP 过程中遇到的问题。因此，本篇文章将针对 ABP 默认生成的模板项目进行精简，构建出一个简化版的 ABP 项目模板

模板源码地址：https://github.com/danvic712/ingos-abp-api-template

Overview

身份认证是网站最基本的功能，最近因为业务部门的一个需求，需要对一个已经存在很久的小工具网站进行改造，因为在逐步的将一些离散的系统迁移至 .NET Core，所以趁这个机会将这个老的 .NET Framework 4.0 的项目进行升级

老的项目是一个 MVC 的项目并且有外网访问的需求，大部门的微服务平台因为和内部的业务执行比较密切，介于资安要求与外网进行了隔离，因此本次升级就不会迁移到该平台上进行前后端分离改造

使用频次不高，不存在高并发，实现周期短，所以就没有必要为了用某些组件而用，因此这里还是选择沿用 MVC 框架，对于网站的身份认证则采用单体应用最常见的 Cookie 认证来实现，本篇文章则是如何实现的一个基础的教程，仅供参考

前言

在 asp.net core 中，存在着中间件这一概念，在中间件中，我们可以比过滤器更早的介入到 http 请求管道，从而实现对每一次的 http 请求、响应做切面处理，从而实现一些特殊的功能

在使用中间件时，我们经常实现的是鉴权、请求日志记录、全局异常处理等等这种非业务性的需求，而如果你有在 asp.net core 中使用过 swashbuckle(swagger)、health check、mini profiler 等等这样的组件的话，你会发现，这些第三方的组件往往都提供了页面，允许我们通过可视化的方式完成某些操作或浏览某些数据

因为自己也需要实现类似的功能，虽然使用到的知识点很少、也很简单，但是在网上搜了搜也没有专门介绍这块的文档或文章，所以本篇文章就来说明如何在中间件中返回页面，如果你有类似的需求，希望可以对你有所帮助

前言

从 18 年开始接触 .NET Core 开始，在私底下、工作中也开始慢慢从传统的 mvc 前后端一把梭，开始转向 web api + vue，之前自己有个半成品的 asp.net core 2.2 的项目模板，最近几个月的时间，私下除了学习 Angular 也在对这个模板基于 asp.net core 3.1 进行慢慢补齐功能

因为涉及到底层框架大版本升级，由于某些 breaking changes 必定会造成之前的某些写法没办法继续使用，趁着端午节假期，在改造模板时，发现没办法通过构造函数注入的形式在 Startup 文件中注入某些我需要的服务了，因此本篇文章主要介绍如何在 asp.net core 3.x 的 startup 文件中获取注入的服务

前言

在进行 Web 项目开发的过程中，可能会存在一些需要经常访问的静态数据，针对这种在程序运行过程中可能几乎不会发生变化的数据，我们可以尝试在程序运行前写入到缓存中，这样在系统后续使用时就可以直接从缓存中进行获取，从而减缓因为频繁读取这些静态数据造成的应用数据库服务器的巨大承载压力。

既然需要在程序运行前将静态数据写入到缓存中，毫无疑问我们需要在程序运行前执行一些自定义功能的代码，那么在本章中，我将会介绍如何在 ASP.NET Core 项目中，实现在程序启动前执行某些特定功能的代码。

前言

        最近有在看 DDD 的相关资料以及微软的 eShopOnContainers 这个项目中基于 DDD 的架构设计，在 Ordering 这个示例服务中，可以看到各层之间的代码调用与我们之前传统的调用方式似乎差异很大，整个项目各个层之间的代码全部是通过注入 IMediator 进行调用的，F12 查看源码后可以看到该接口是属于 MediatR 这个组件的。既然要照葫芦画瓢，那我们就先来了解下如何在 ASP.NET Core 项目中使用 MediatR。
        仓储地址：https://github.com/Lanesra712/ingos-common/tree/master/sample/aspnetcore/aspnetcore-mediatr-tutorial

前言

        在实际项目开发过程中，我们使用到的各种 ORM 组件都可以很便捷的将我们获取到的数据绑定到对应的 List<T> 集合中，因为我们最终想要在页面上展示的数据与数据库实体类之间可能存在很大的差异，所以这里更常见的方法是去创建一些对应于页面数据展示的 视图模型 类，通过对获取到的数据进行二次加工，从而满足实际页面显示的需要。
        因此，如何更便捷的去实现 数据库持久化对象 与 视图对象 间的实体映射，避免我们在代码中去一次次的手工实现这一过程，就可以降低开发的工作量，而 AutoMapper 则是可以帮助我们便捷的实现实体转换这一过程的利器。所以，本章我们就来学习如何在 ASP.NET Core 项目中通过使用 AutoMapper 去完成实体间的映射。
        当然，如果你习惯于从视图展现到持久化到数据库都采用数据库实体，那么本篇文章对你可能不会有任何的帮助。
        仓储地址：https://github.com/Lanesra712/ingos-common/tree/master/sample/aspnetcore/aspnetcore-automapper-tutorial

前言

        在目前的软件开发的潮流中，不管是前后端分离还是服务化改造，后端更多的是通过构建 API 接口服务从而为 web、app、desktop 等各种客户端提供业务支持，如何构建一个符合规范、容易理解的 API 接口是我们后端开发人员需要考虑的。在本篇文章中，我将列举一些我在使用 ASP.NET Core Web API 构建接口服务时使用到的一些小技巧，因才疏学浅，可能会存在不对的地方，欢迎指出。
        仓储地址：https://github.com/Lanesra712/ingos-server

前言

        不知你在平时上网时有没有注意到，绝大多数网站的 URL 地址都是小写的英文字母，而我们使用 .NET/.NET Core MVC 开发的项目，因为在 C# 中类和方法名采用的是 Pascal 命名规范，根据 .NET 框架默认的路由规则，项目的 URL 地址会呈现出大小写混合的情况。对于强迫症来说，这种情况绝对不能忍，当然，由于整个项目的 URL 地址大小写混合显示，也无法更清晰的向用户、浏览器表达出当前页面的功能。那么，这篇文章就来介绍下，如何调整我们的 ASP.NET Core 项目的路由规则，从而使我们项目的 URL 地址可读性更高。
        PS：在构建 URL 的过程中，采用大写的地址还是采用小写的地址，每个人都会有自己的想法和这样做的理由，这篇文章不讨论两种方案的优劣，只是提供一种构建小写 URL 地址以及让我们的 URL 可读性更高的解决方案，请友善观看，切勿互怼。
        仓储地址：https://github.com/Lanesra712/ingos-common/tree/master/sample/aspnetcore/aspnetcore-route