【开源】跨语言·跨平台·跨数据库(6) ——一种ORM缓存的接口实现和容错处理

【开源】跨语言·跨平台·跨数据库(6) ——一种ORM缓存的接口实现和容错处理

2026-07-21

作者：周方勇 / 咏方舟-长江支流（金质打印通、用宝框架开源作者）

用宝框架 ·拥抱第一 · 一次书写 · 三端复用

用宝框架是开源轻量级企业级分层架构基架，也是开放的、可扩展的架构体系。.NET Standard 2.0，零依赖，支持 MySQL / SQL Server / Oracle / SQLite并可扩展。SQL就是最好的跨平台语言，可跨语言无缝迁移至鸿蒙 ArkTS 及 Java 技术栈，接口名、类名、方法签名三端完全一致。

用宝架构开发的所有应用，可直接移植到 Java/ArkTS，无需重新设计架构、无需重新分层、无需重新抽象业务逻辑，只需按目标语言语法做形式上的转换。

本文侧重：接上文一种可插入式缓存接口设计将ICacheProvider接口，用于ORM上。在针对ORM的实体做缓存时，如果使用者忘记这个强大的功能没有应用DI，依赖注入没有怎么办？这里提供了几种方式及容错处理。

ORM缓存基类

缓存基类，采用继承框架IEntity接口的针对实体映射的IMapEntity接口，体现了面向对象基于接口编程的方法。

usingSystem;usingSystem.IO;usingUserBaoTech.Foundation.Data;usingUserBaoTech.Foundation.Entities;usingUserBaoTech.Foundation.Infrastructure;usingUserBaoTech.Foundation.UbException;namespaceUserBaoTech.Foundation.ORM.Cache{/// <summary>/// 作者：长流支流 2026-07-21/// 实体缓存管理器基类 —— 提供模板缓存、刷新、文件变更检测能力/// 缓存直接存储 TEntity 类型，避免类型转换/// </summary>/// <typeparam name="TEntity">实体类型，必须实现 IMapEntity&lt;string&gt;</typeparam>publicabstractclassEntityCacheManager<TEntity>whereTEntity:IMapEntity<string>{privatereadonlystring_contentRootPath;privatereadonlyICacheProvider_cacheProvider;privateconststringCACHE_KEY_PREFIX="EntityCache_";protectedEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider){_contentRootPath=contentRootPath;_cacheProvider=cacheProvider??newNullCacheProvider();}protectedstringContentRootPath{get{return_contentRootPath;}}protectedICacheProviderCacheProvider{get{return_cacheProvider;}}privatestringGetCacheKey(stringname){returnCACHE_KEY_PREFIX+name;}/// <summary>/// 获取或加载缓存/// </summary>publicTEntityGetOrLoad(stringname){if(string.IsNullOrEmpty(name)){thrownewUserBaoException("缓存名称不能为空","CACHE_KEY_EMPTY");}stringcacheKey=this.GetCacheKey(name);// 1. 检查缓存是否存在if(_cacheProvider.Exists(cacheKey)){TEntitycached=_cacheProvider.Get<TEntity>(cacheKey);if(cached!=null){// 检查文件是否变更stringfilePath=this.GetFilePath(name);if(File.Exists(filePath)){DateTimecurrentFileTime=File.GetLastWriteTime(filePath);DateTimecachedFileTime=this.GetFileTimeFromEntity(cached);if(currentFileTime>cachedFileTime){// 文件已变更，重新加载returnthis.LoadAndCache(name);}}returncached;}}// 2. 缓存未命中或文件已变更，重新加载returnthis.LoadAndCache(name);}/// <summary>/// 加载并缓存/// </summary>privateTEntityLoadAndCache(stringname){stringfilePath=this.GetFilePath(name);if(!File.Exists(filePath)){thrownewUserBaoException("配置文件不存在："+filePath,"CONFIG_NOT_FOUND");}// 由子类实现具体的加载逻辑TEntityentity=this.LoadFromFile(filePath);// 将文件修改时间存入实体（由子类重写）DateTimelastWrite=File.GetLastWriteTime(filePath);this.SetFileTimeToEntity(entity,lastWrite);// 存入缓存stringcacheKey=this.GetCacheKey(name);_cacheProvider.Set(cacheKey,entity);returnentity;}/// <summary>/// 子类实现：从文件加载实体/// </summary>protectedabstractTEntityLoadFromFile(stringfilePath);/// <summary>/// 从实体中获取文件修改时间（子类可重写）/// </summary>protectedvirtualDateTimeGetFileTimeFromEntity(TEntityentity){// 默认返回最小值，由子类根据具体实体类型重写returnDateTime.MinValue;}/// <summary>/// 将文件修改时间存入实体（子类可重写）/// </summary>protectedvirtualvoidSetFileTimeToEntity(TEntityentity,DateTimefileTime){// 默认不做任何事，由子类重写}/// <summary>/// 获取文件路径（子类可重写）/// </summary>protectedvirtualstringGetFilePath(stringname){// 默认：ContentRootPath + "/Configs/" + name + ".xml"stringrelativePath=name.Replace('/',Path.DirectorySeparatorChar);returnPath.Combine(_contentRootPath,"Configs",relativePath+".xml");}/// <summary>/// 刷新指定缓存/// </summary>publicvoidRefresh(stringname,boolloadImmediately=false){if(string.IsNullOrEmpty(name)){this.RefreshAll(loadImmediately);return;}stringcacheKey=this.GetCacheKey(name);_cacheProvider.Remove(cacheKey);if(loadImmediately){this.LoadAndCache(name);}}/// <summary>/// 刷新所有缓存/// </summary>publicvoidRefreshAll(boolloadImmediately=false){_cacheProvider.Clear();if(loadImmediately){// 由于 ICacheProvider.Clear() 清空了所有缓存，// 但无法枚举所有 key，由调用方自行逐个刷新// 此处仅保留方法签名兼容}}/// <summary>/// 检查缓存是否存在/// </summary>publicboolExists(stringname){stringcacheKey=this.GetCacheKey(name);return_cacheProvider.Exists(cacheKey);}/// <summary>/// 获取缓存项（不触发加载）/// </summary>publicTEntityGet(stringname){stringcacheKey=this.GetCacheKey(name);if(_cacheProvider.Exists(cacheKey)){return_cacheProvider.Get<TEntity>(cacheKey);}returndefault(TEntity);}}}

架构闭环

您的想法方向正确，但需要更精细的设计。直接去掉abstract并让LoadFromFile返回null，会破坏GetOrLoad的健壮性——它会在LoadAndCache中拿到null并试图存缓存，导致空引用异常。

EntityCacheManager抽象/实例类方案

在这种，采用一一种叫模式方法的设计模式，在LoadAndCache(string name)方法中调用 this.LoadFromFile(filePath);是为了更好的对有扩展需求的设计，有的灵活配置在文件中。面向对象核心是抽象、重载、多态。

因此，将EntityCacheManager设计为抽象类，LoadFromFile（）设计为抽象方法，意味着EntityCacheManager不能直接实例化，即不能new EntityCacheManager()，那么子类必须实现LoadFromFile（）方法。

方案一：将EntityCacheManager拆分为两个独立类

1. 抽象基类（保留现有设计，用于 ORM写死的实体如Products实体类、AnyORM 等动态实体）

publicabstractclassEntityCacheManager<TEntity>whereTEntity:IMapEntity<string>{// 现有全部代码保持不变protectedabstractTEntityLoadFromFile(stringfilePath);// ...}

2. 新增具体实现类（用于静态实体）

publicclassStaticEntityCacheManager<TEntity>:EntityCacheManager<TEntity>whereTEntity:IMapEntity<string>,new(){privatereadonlyFunc<string,TEntity>_loader;// 由调用方传入加载逻辑publicStaticEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider,Func<string,TEntity>loader):base(contentRootPath,cacheProvider){_loader=loader;}protectedoverrideTEntityLoadFromFile(stringfilePath){// 静态实体不需要从文件加载，直接返回新实例（或由调用方决定）// 如果确实需要从文件加载，可以用 _loader(filePath)returnnewTEntity();}}

方案二：将LoadFromFile改为虚方法（非抽象）

publicclassEntityCacheManager<TEntity>whereTEntity:IMapEntity<string>{// 改为虚方法，默认实现返回 null（但调用方需判断）protectedvirtualTEntityLoadFromFile(stringfilePath){returndefault(TEntity);}privateTEntityLoadAndCache(stringname){stringfilePath=GetFilePath(name);// ...TEntityentity=LoadFromFile(filePath);if(entity==null){// 静态实体可在此处创建默认实例entity=Activator.CreateInstance<TEntity>();}// ...}}

这样静态实体继承时不需要实现LoadFromFile，但需要在LoadAndCache中处理null分支。

方案三（推荐）：独立出“实体工厂”接口

将“如何获取实体”抽象为独立接口，缓存管理器依赖此接口，而非自身实现加载逻辑。

publicinterfaceIEntityLoader<TEntity>whereTEntity:IMapEntity<string>{TEntityLoad(stringidentifier);// identifier 可以是文件路径或名称}publicclassEntityCacheManager<TEntity>whereTEntity:IMapEntity<string>{privatereadonlyIEntityLoader<TEntity>_loader;publicEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider,IEntityLoader<TEntity>loader){// ..._loader=loader;}privateTEntityLoadAndCache(stringname){// ...TEntityentity=_loader.Load(filePath);// ...}}

这样：

• AnyORM：提供XEntityLoader（解析 配置）
• 静态实体：提供StaticEntityLoader（return new TEntity()）
• 完全解耦，无需修改基类

您倾向哪种方案？

• 方案一：保留抽象基类，新增静态实体专用派生类。
• 方案二：将抽象方法改为虚方法，默认返回默认值。
• 方案三：引入IEntityLoader<T>接口，彻底解耦。

如果你让AI来选，AI估计 选方案二，AI生成代码就喜欢一步到位完成功能，不考虑灵活复用性，但主技术控来选，很可能建议方案三，因为它最灵活且符合开闭原则。读者有什么想法？

我说，方案二，耦合性太大，方案三是过度设计，我们搞ORM，会只做动态、静态实体，用方案一抽象基类派生最合适。

用宝开源ORM是必须用DI吗？

前面说了，应用程序启动时，提供一个 builder.Services.AddSingleton<ICacheProvider, NullCacheProvider>(); 注册，以防止报错。因为我们继承EntityCacheManager的时候，要注入ICacheProvider 的接口实例，此时一个小技巧是发现使用者没有DI注册，这时，在构造函数注入的时候做一个判断，以便引入一个默认什么也没有做的实例new NullCacheProvider()。

/// <summary>/// XML 实体缓存管理器 —— 继承 EntityCacheManager，专用于 XmlMapEntity/// 支持外部 ICacheProvider 和内部后备缓存（内存字典）双机制/// </summary>publicclassXmlEntityCacheManager:EntityCacheManager<XmlMapEntity>{privatereadonlyXmlEntityParser_parser;privatereadonlyIDataDictionary<string,XmlMapEntity>_fallbackCache;publicXmlEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider,XmlEntityParserparser):base(contentRootPath,cacheProvider??newNullCacheProvider()){_parser=parser??thrownewArgumentNullException(nameof(parser));_fallbackCache=newDataDictionary<string,XmlMapEntity>();}}

架构闭环

用户请求 ↓ EntityCacheManager.GetOrLoad() ↓ 外部 ICacheProvider 存在且有效？ ├── 是 → Redis/MemoryCache（分布式、高可用、可观测） └── 否 → 内部内存字典（零配置、单机、保运行） ↓ 返回模板 → 业务处理

使用者没依赖注入

上面说了使用都根本以为你这ORM是个最基本的东西，根据没相到程序启动时要注册？ 但是你用new NullCacheProvider()其实什么也没做，内部怎么处理，其实外部没注册可以用 *内部内存字典（_fallbackCache）

• 与真正的缓存实现（ICacheProvider）的核心差异：

设计结论

_fallbackCache的定位是“生存保障”：

• 用户不配缓存 → 能跑。
• 用户缓存出问题 → 能跑。
• 单机小应用 → 够用。

ICacheProvider的定位是“性能与扩展”：

• 分布式多实例 → 共享缓存，减少重复解析。
• 高并发 → 缓存失效策略可控。
• 生产环境 → 可观测、可调优。

当前代码是“先外部，后内部”的双层容错

用户请求 → GetOrLoad() ↓ 外部 ICacheProvider 是否可用（非 NullCacheProvider）？ ├── 是 → 使用外部缓存（高性能、分布式、可控） └── 否 → 自动降级到内部内存字典（零配置、无感知、保运行）

这样设计，既保证了“零配置开箱即用”，又为高级用户保留了“可插拔高性能缓存”的扩展能力。符合框架“轻量、易用、不强制依赖”的定位。

欢迎拷贝、转载，无需授权
反馈与交流：欢迎在评论区留言或私信交流。如果你正在寻找一套不用 EF、不用 Dapper、可跨语言迁移的轻量级基架，用宝框架或许是一个值得尝试的选择。

用宝框架，拥抱第一 · 一次书写 · 三端复用——不仅是用户的朋友，而且是用户的宝贝