dotNET Core 3.X 依赖注入
如果说在之前的 dotNET 版本中,依赖注入还是个比较新鲜的东西,那么在 dotNET Core 中已经是随处可见了,可以说整个 dotNET Core 的框架是构建在依赖注入框架之上。本文讲解下对 dotNET Core 中依赖注入的理解。
如果说在之前的 dotNET 版本中,依赖注入还是个比较新鲜的东西,那么在 dotNET Core 中已经是随处可见了,可以说整个 dotNET Core 的框架是构建在依赖注入框架之上。本文讲解下对 dotNET Core 中依赖注入的理解。
好的工具和流程能使我们事半功倍,而这个过程是不断迭代和演进的。关于这一块的内容,之前写过几篇文章: 在团队中使用GitLab中的Merge Request工作模式 敏捷下的需求和代码分支管理 不断进化的分支和需求管理 现在又有了些新的变化和改进,之所以需要改进,肯定是遇到问题了,那么就先从问题来开始今天的文章。
在前后端分离的架构中,前端需要通过 API 接口的方式获取数据,但 API 是无状态的,没有办法知道每次请求的身份,也就没有办法做权限的控制。如果不做控制,API 就对任何人敞开了大门,只要拿到了接口地址就可以进行调用,这是非常危险的。本文主要介绍下在 dotNET Core Web API 中使用 Jwt 来实现接口的认证。
理解 dotNET Core 中的管道模型,对我们学习 dotNET Core 有很大的好处,能让我们知其然,也知其所以然,这样在使用第三方组件或者自己写一些扩展时,可以避免入坑,或者说避免同样的问题多次入坑。
现在的 Web 开发大多都是前后端分离的方式,后端接口的正确使用显得尤为重要,本文讲下在 dotNET Core 3.X 下使用 Web API 。
之前的自动构建工具 Jenkins 是部署在公司内网的 Windows 服务器上,现在武汉处于非常时期,兄弟们都在家自我隔离,为了远程提交的代码能自动构建,需要在外网的 CentOS 服务器上搭建 Jenkins 环境来进行构建工作。
在之前的文章《dotNET Core 中怎样操作 AD?》中主要以将AD的数据同步到数据库的场景来描述了在 dotNetCore 中怎样操作AD,本文将继续介绍一些在 dotNetCore 中操作 AD 的其他常用操作。
现在说到使用缓存中间件基本就是 Redis 了,通常开发环境或测试环境部署一个单机版就可以运行了,但要上生产环境还需要进行高可用的方式来部署,本文说说在 CentOS7 中 Redis 高可用的部署以及在 dotNetCore 中怎样调用。
自从产品转到了 dotNET Core 之后,更深入的接触 Linux和 Docker ,而我每天的工作中,有一部分时间相当于在“兼职”做一些运维的事情。下面是一些在日常中常用的命令,算是个备忘吧。
业务背景在我们的日常开发中,经常需要调用第三方接口来进行数据传递,在调用接口的过程中,会因为各种原因导致调用的失败。这时我们希望能有一种机制实现对失败的接口的重复调用,并且能够实现人工干预。