Alby's blog

一、概述

无意翻到之前看《深入理解计算机系统》一书时对 2.2.4 节的关于“无符号数和有符号数互转公式的证明” 的手写笔记。比较简单，但也整理一下。

对大多数 C 语言的实现而言，处理同样字长的有符号数和无符号数之间相互转换的一般规则是：数值可能会改变，但是位模式不变。

一、概述

工作单元是”对象-关系”行为的一种模式。维护受业务事务影响的对象列表，并协调变化的写入和并发问题的解决。——《企业应用架构模式》

1、工作单元的作用

工作单元只是将所有修改状态保存下来，在适当的时候在同一数据库连接和事务处理上下文中一次性将对象的变更提交到数据中。额外的优点是既减少了数据库调用次数，又避免数据库长事务。

同一个工作单元一般不要跨线程使用。

2、工作单元和仓储(Repository)模式

工作单元常与仓储(Repository)模式一起使用。因为多个 Repository 可能做出多处更改，如果在 Repository 中调用 DbContext.SaveChanges 或 DbContext.SaveChangesAsync（如果使用 Entity Framework 的话），则产生了多个相互隔离开的事务。

实际上 Entity Framewok 也实现了仓储模式(DbSet<T>)和工作单元模式(DbContext)。

3、工作单元和依赖注入(拦截器)

直接使用工作单元也是可以的。配合依赖注入和拦截器能将工作单元的创建和完成提交的工作自动化，也就是说避免了手工创建工作单元和手工调用 Complete/Commit 。这种自动化使得应对复杂业务逻辑时不用过于关注业务无关的事务安全问题。

一、概述

Abp 的 DI 容器是基于 Microsoft 的依赖注入扩展库（Microsoft.Extensions.DependencyInjection nuget包）开发的。因此，它的文档在 Abp 中也是有效的。
Abp 中可以使用 Autofac 替换内置 DI 容器的，以支持属性注入和动态代理（拦截器）。

Abp 提供的服务自动注册功能用内置的 DI 容器也能实现。

一、概述

去年写过一篇《ASP.NET Core 授权的扩展：自定义 Authorize Attribute 和 IApplicationModelProvide》，由于在 ASP.NET Core 3 中，Microsoft.AspNetCore.Mvc.Internal 命名空间下的 AuthorizationApplicationModelProvider 类由 public 被改为了 internal，使得无法方便地将其从容器中 DI 容器中移除，所以不得不回到 IAuthorizationPolicyProvider 上来。

ASP.NET Core 提供了基于角色( Role )、声明( Chaim ) 和策略 ( Policy ) 等的授权方式。在实际应用中，可能采用部门（ Department , 本文采用用户组 Group ）、职位 ( 可继续沿用 Role )、权限( Permission )的方式进行授权。本文通过自定义 IAuthorizationPolicyProvider 进行扩展。

一、概述

Abp 本身是一个包含许多 nuget 包的模块化框架。它还提供了一个完整的基础架构来开发你自己的具有实体、服务、数据库集成、AP、UI 组件等等功能的应用程序模块。
每个模块都应该定义一个模块类。模块类指实现了 IAbpModule 接口的非抽象非泛型类。定义模块类的最简单方法是创建一个派生自 AbpModule 的类，AbpModule 是一个实现了 AbpModule 接口的抽象非泛型类。

一、概述

Abp 是一个开源应用程序框架，专注于基于 ASP.NET Core 的 Web 应用程序开发，但也支持开发其他类型的应用程序。
本文先分析相关的几个类型，再分析 Abp 的启动流程。

一、概述

表达式树( Expression Tree )以树形数据结构表示代码，其中每一个节点都是一种表达式。
本文通过 API 创建表达式树，以满足某些不方便根据 Lambda 表达式创建表达式树的情况。

一、概述

本文将会根据情况持续更新。
作为一个 Framework，ASP.NET Core 提供了诸多的扩展点。使用内置的组件和默认的配置通常就能够满足部分需求，当需要扩展的时就需要先去找出这些扩展点。除了基于实际应用对 ASP.NET Core 进行扩展，也会故意搞一些不切实际的伪需求，解决一些不会存在的问题。这样的目的何在呢？一是为了加深对 ASP.NET Core 的理解，二是难保这些伪需求不会变成真需求。

一、概述

ASP.NET Core 提供了基于角色( Role )、声明( Chaim ) 和策略 ( Policy ) 等的授权方式。在实际应用中，可能采用部门（ Department , 本文采用用户组 Group ）、职位 ( 可继续沿用 Role )、权限( Permission )的方式进行授权。要达到这个目的，仅仅通过自定义 IAuthorizationPolicyProvider 是不行的。本文通过自定义 IApplicationModelProvide 进行扩展。

一、概述

通常我们会在 Startup 类通过 void ConfigureServices(IServiceCollection services) 配置应用的服务。常见的形如 AddXXX 的方法，实际上调用的都是 IServiceCollection 或直接说是 ServiceCollection 的 AddSingleton 、AddTransient 和 AddScoped等方法。调用ApplicationBuilder 的 RequestDelegate Build() 方法会调用 IServiceCollection 的扩展方法 BuildServiceProvider 会创建并返回一个 ServiceProvider 对象。
还会在 Startup 类通过 void Configure(IApplicationBuilder app, IHostingEnvironment env) 配置请求管道，在该方法内进行的主要操作是添加中间件。常见的形如 UseMiddleware 或 UseXXX 的方法，实际上调用的都是 IApplicationBuilder 或直接说是 ApplicationBuilder 的 IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware) 方法，Use 方法并不是马上将中间件配置入请求管道，而是将“实例化中间件的方式”保存到 ApplicationBuilder 内部一个列表的操作。调用ApplicationBuilder 的 RequestDelegate Build() 方法会实例化中间件并把各个中间件串联起来。