ABP源码分析三十：ABP.RedisCache

ABP 通过StackExchange.Redis类库来操作Redis数据库。

AbpRedisCacheModule：完成ABP.RedisCache模块的初始化(完成常规的依赖注入)

AbpRedisCacheConfig：定义了connectionStringKey和databaseIdAppSetting的值。这两个值对象redis 在web.config中的key值。 ABP.RedisCache模块通过读取web.config来获取redis的配置。

IAbpRedisConnectionProvider/AbpRedisConnectionProvider:从web.config中读取Redis的connectionstring信息，并通过connectionstring生成ConnectionMultiplexer对象。AbpRedisConnectionProvider是一个单例实现，并且将ConnectionMultiplexer对象保存在其本地的Dictionary中，避免反复创建。

AbpRedisCache : 继承自Abp核心库中的 CacheBase，通过IAbpRedisConnectionProvider对象返回的ConnectionMultiplexer对象操作redis数据库。

AbpRedisCacheManager：重写了CacheManagerBase的CreateCacheImplementation方法，该方法用于创建真实的Icache对象。 具体到AbpRedisCacheManager就是创建AbpRedisCache。

如何启用RedisCache呢？

默认情况下ABP是将AbpMemoryCacheManager注入到容器中的（是在ABPKernelModule的initalize方法中完成的）。所以我们要让AbpRedisCacheManager先于AbpMemoryCacheManager注入到容器中，这样castle 在resolve系统中的ICacheManager的时候就会优先取得AbpRedisCacheManager。方法只有一个，就是在你的web项目的**Module的PreInitialize中完成AbpRedisCacheManager的register(因为ABP是在完成所有moudle类的PreInitialize方法后，才执行各个Module的initalize方法的)。

返回ABP源码分析系列文章目录

时间： 2024-10-08 10:34:44

ABP源码分析三十：ABP.RedisCache的相关文章

ABP源码分析三十五：ABP中动态WebAPI原理解析

动态WebAPI应该算是ABP中最Magic的功能之一了吧.开发人员无须定义继承自ApiController的类,只须重用Application Service中的类就可以对外提供WebAPI的功能,这应该算是对DRY的最佳诠释了. 如下图所示,一行代码就为所有实现了IApplicationService的类型,自动创建对应的动态WebAPI. 这么Magic的功能是如何实现的呢? 本文为你揭开其Magic的外表.你会发现,实现如此Magic的功能,最关键的代码只有四行. 先思考一个问题:如果不

ABP源码分析三十六：ABP.Web.Api

这里的内容和ABP 动态webapi没有关系.除了动态webapi,ABP必然是支持使用传统的webApi.ABP.Web.Api模块中实现了一些同意的基础功能,以方便我们创建和使用asp.net webApi. AbpApiController:这是一个抽象基类,继承自ApiController,是AB WebApi系统中所有controller的基类.如下图中,其封装了ABP核心模块中提供的大多数的功能对象.同时实现了一些公共的方法.它有四个派生类:DynamicApiController<

ABP源码分析三十二：ABP.SignalR

Realtime Realtime是ABP底层模块提供的功能,用于管理在线用户.它是使用SignalR实现给在线用户发送通知的功能的前提 IOnlineClient/OnlineClient: 封装在线用户的信息 OnlineClientManager/IOnlineClientManager: 用于提供基本维护在线用户的方法.其内部维护了一个字典来保存在线的客户信息. SingalR SignalRRealTimeNotifier: 实现了给在线用户发送通知的功能.其从IOnlineClien

ABP源码分析三：ABP Module

Abp是一种基于支持模块化设计的思想构建的.具体的功能都可以设计成一个单独的Module.Abp底层框架提供便捷的方法集成每个Module.下图是所有Abp自带的module.AbpModule是所有Module的基类,其已经拥有了IIocManager和IAbpStartupConfiguration的受保护的成员,从其派生的Module都可以直接获取并使用相关的功能.: 以下以AbpWebMvcModule为例,这个就是Abp自定义的一个模块,该模块继承自AbpModule. 那么这个模块是

ABP源码分析三十三：ABP.Web

ABP.Web模块并不复杂,主要完成ABP系统的初始化和一些基础功能的实现. AbpWebApplication : 继承自ASP.Net的HttpApplication类,主要完成下面三件事一,在Application_Start完成AbpBootstrapper的初始化.整个ABP系统的初始化就是通过AbpBootstrapper完成初始化的.二,在Application_BeginRequest设置根据request或cookie中的Culture信息,完成当前工作线程的CurrentCu

ABP源码分析三十一：ABP.AutoMapper

这个模块封装了Automapper,使其更易于使用. 下图描述了改模块涉及的所有类之间的关系. AutoMapAttribute,AutoMapFromAttribute和AutoMapToAttribute:这三个attribute用于标注一个类到另外一个类的map方向. AutoMapperHelper: 通过调用Automapper的API,根据类的AutoMap的特性完成类型之间的Map. AbpAutoMapperModule: 1. 查找项目中所有标注了AutoMap特性的类型,并完

ABP源码分析二十六：核心框架中的一些其他功能

本文是ABP核心项目源码分析的最后一篇,介绍一些前面遗漏的功能 AbpSession AbpSession: 目前这个和CLR的Session没有什么直接的联系.当然可以自定义的去实现IAbpSession使之与CLR的Session关联 IAbpSession:定义如下图中的四个属性. NullAbpSession:IAbpSession的一个缺省实现,给每个属性都给予null值,无实际作用 ClaimsAbpSession:实现了从ClaimsPrincipal/ClaimsIdentity

ABP源码分析二十八：ABP.MemoryDB

这个模块简单,且无实际作用.一般实际项目中都有用数据库做持久化,用了数据库就无法用这个MemoryDB 模块了.原因在于ABP限制了UnitOfWork的类型只能有一个(前文以作介绍),一般用了数据库的必然要注入efUnitOfWork. 而注入了efUnitOfWork就不能在注入MemoryDbUnitOfWork了. MemoryDatabase:这是一个单例.ABP通过Dictionary<Type, object>+lock作为数据结构来实现内存数据库.其以entity的类型作为ke

ABP源码分析四十六：ABP ZERO中的Ldap模块

通过AD作为用户认证的数据源.整个管理用户认证逻辑就在LdapAuthenticationSource类中实现. LdapSettingProvider:定义LDAP的setting和提供DefautValue.主要提供配置访问AD数据库的账号信息. LdapSettings/ILdapSettings:通过settingManager获取LDAP settings AbpZeroLdapModuleConfig/IAbpZeroLdapModuleConfig: 提供激活Ldap认证的配置.