Abp vNext 源码分析 - 9. 接口参数的认证

一、简要说明

ABP vNext 针对接口参数的校验工作,分别由过滤器和拦截器两步完成。过滤器内部使用的 ASP.NET Core MVC 所提供的 IModelStateValidator 进行处理,而拦截器使用的是 ABP vNext 自己提供的一套 IObjectValidator 进行校验工作。

关于参数验证相关的代码,分布在以下三个项目当中:

  • Volo.Abp.AspNetCore.Mvc
  • Volo.Abp.Validation
  • Volo.Abp.FluentValidation

通过 MVC 的过滤器和 ABP vNext 提供的拦截器,我们能够快速地对接口的参数、对象的属性进行统一的验证处理,而不会将这些代码扩散到业务层当中。

文章信息:

基于的 ABP vNext 版本:1.0.0

创作日期:2019 年 10 月 22 日晚

更新日期:暂无

为什么要实现 IDisposable 接口?

一、背景

最近在精读 《CLR Via C#》和 《Effective C#》 的时候,发现的一个问题点。一般来说,我们实现 IDisposable 接口,是为了释放托管资源和非托管资源。不过在 C# 类型定义里面有一个功能类似的东西,那就是 终结器

最开始我是学 C++ 的,之后学 C# 的时候发现这玩意儿不论是写法和作用,都跟 C++ 里面的 析构函数 一样。在 C++ 里面的析构函数是在对象释放的时候会被调用,之后这个观点一直被我带到 C#,认为资源释放的动作放在终结器不就行了么。为什么还要我实现 IDisposable 接口,然后让使用者手动释放呢?

C++ 版本的析构函数:

1
2
3
4
5
6
7
8
9
class Line
{
   public:
      Line();  
      ~Line(); 
 
    private:
      double length;
};

C# 版本的终结器:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
public class Line
{
    private double _length;
    
    public Line()
    {
        
    }
    
    ~Line()
    {
        
    }
}

ABP vNext 不使用工作单元为什么会抛出异常

一、问题

该问题经常出现在 ABP vNext 框架当中,要复现该问题十分简单,只需要你注入一个 IRepository<T,TKey> 仓储,在任意一个地方调用 IRepository<T,TKey>.ToList() 方法。

1
2
3
4
5
6
7
[Fact]
public void TestMethod()
{
    var rep = GetRequiredService<IHospitalRepository>();

    var result = rep.ToList();
}

例如上面的测试代码,不出意外就会提示 System.ObjectDisposedException 异常,具体的异常内容信息:

1
System.ObjectDisposedException : Cannot access a disposed object. A common cause of this error is disposing a context that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application. This may occur if you are calling Dispose() on the context, or wrapping the context in a using statement. If you are using dependency injection, you should let the dependency injection container take care of disposing context instances.

其实已经说得十分明白了,因为你要调用的 DbContext 已经被释放了,所以会出现这个异常信息。

Abp vNext 源码分析 - 8. 审计日志

一、简要说明

ABP vNext 当中的审计模块早在 **依赖注入与拦截器**一文中有所提及,但没有详细的对其进行分析。

审计模块是 ABP vNext 框架的一个基本组件,它能够提供一些实用日志记录。不过这里的日志不是说系统日志,而是说接口每次调用之后的执行情况(执行时间、传入参数、异常信息、请求 IP)。

除了常规的日志功能以外,关于 实体聚合 的审计字段接口也是存放在审计模块当中的。(创建人创建时间修改人修改时间删除人删除时间

Jenkins 结合 Docker 实现低配版的 CI&CD

随着项目的不断增多,最开始单体项目手动执行 docker build 命令,手动发布项目就不再适用了。一两个项目可能还吃得消,10 多个项目每天让你构建一次还是够呛。即便你的项目少,每次花费在发布上面的时间累计起来都够你改几个 BUG 了。

所以我们需要自动化这个流程,让项目的发布和测试不再这么繁琐。在这里我使用了 Jenkins 作为基础的 CI/CD Pipeline 工具,关于 Jenkins 的具体介绍这里就不再赘述。在版本管理、构建项目、单元测试、集成测试、环境部署我分别使用到了 GogsDockerDocker Swarm(已与 Docker 整合) 这几个软件协同工作。

以下步骤我参考了 Continuous Integration with Jenkins and Docker 一文,并使用了作者提供的 groovy 文件和 slave.py 文件。

关于 Docker-CE 的安装,请参考我的另一篇博文 《Linux 下的 Docker 安装与使用》

Built with Hugo
主题 StackJimmy 设计