【开源】跨语言·跨平台·跨数据库(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 nameTEntity实体类型必须实现 IMapEntitylt;stringgt;/typeparampublicabstractclassEntityCacheManagerTEntitywhereTEntity:IMapEntitystring{privatereadonlystring_contentRootPath;privatereadonlyICacheProvider_cacheProvider;privateconststringCACHE_KEY_PREFIXEntityCache_;protectedEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider){_contentRootPathcontentRootPath;_cacheProvidercacheProvider??newNullCacheProvider();}protectedstringContentRootPath{get{return_contentRootPath;}}protectedICacheProviderCacheProvider{get{return_cacheProvider;}}privatestringGetCacheKey(stringname){returnCACHE_KEY_PREFIXname;}/// summary/// 获取或加载缓存/// /summarypublicTEntityGetOrLoad(stringname){if(string.IsNullOrEmpty(name)){thrownewUserBaoException(缓存名称不能为空,CACHE_KEY_EMPTY);}stringcacheKeythis.GetCacheKey(name);// 1. 检查缓存是否存在if(_cacheProvider.Exists(cacheKey)){TEntitycached_cacheProvider.GetTEntity(cacheKey);if(cached!null){// 检查文件是否变更stringfilePaththis.GetFilePath(name);if(File.Exists(filePath)){DateTimecurrentFileTimeFile.GetLastWriteTime(filePath);DateTimecachedFileTimethis.GetFileTimeFromEntity(cached);if(currentFileTimecachedFileTime){// 文件已变更重新加载returnthis.LoadAndCache(name);}}returncached;}}// 2. 缓存未命中或文件已变更重新加载returnthis.LoadAndCache(name);}/// summary/// 加载并缓存/// /summaryprivateTEntityLoadAndCache(stringname){stringfilePaththis.GetFilePath(name);if(!File.Exists(filePath)){thrownewUserBaoException(配置文件不存在filePath,CONFIG_NOT_FOUND);}// 由子类实现具体的加载逻辑TEntityentitythis.LoadFromFile(filePath);// 将文件修改时间存入实体由子类重写DateTimelastWriteFile.GetLastWriteTime(filePath);this.SetFileTimeToEntity(entity,lastWrite);// 存入缓存stringcacheKeythis.GetCacheKey(name);_cacheProvider.Set(cacheKey,entity);returnentity;}/// summary/// 子类实现从文件加载实体/// /summaryprotectedabstractTEntityLoadFromFile(stringfilePath);/// summary/// 从实体中获取文件修改时间子类可重写/// /summaryprotectedvirtualDateTimeGetFileTimeFromEntity(TEntityentity){// 默认返回最小值由子类根据具体实体类型重写returnDateTime.MinValue;}/// summary/// 将文件修改时间存入实体子类可重写/// /summaryprotectedvirtualvoidSetFileTimeToEntity(TEntityentity,DateTimefileTime){// 默认不做任何事由子类重写}/// summary/// 获取文件路径子类可重写/// /summaryprotectedvirtualstringGetFilePath(stringname){// 默认ContentRootPath /Configs/ name .xmlstringrelativePathname.Replace(/,Path.DirectorySeparatorChar);returnPath.Combine(_contentRootPath,Configs,relativePath.xml);}/// summary/// 刷新指定缓存/// /summarypublicvoidRefresh(stringname,boolloadImmediatelyfalse){if(string.IsNullOrEmpty(name)){this.RefreshAll(loadImmediately);return;}stringcacheKeythis.GetCacheKey(name);_cacheProvider.Remove(cacheKey);if(loadImmediately){this.LoadAndCache(name);}}/// summary/// 刷新所有缓存/// /summarypublicvoidRefreshAll(boolloadImmediatelyfalse){_cacheProvider.Clear();if(loadImmediately){// 由于 ICacheProvider.Clear() 清空了所有缓存// 但无法枚举所有 key由调用方自行逐个刷新// 此处仅保留方法签名兼容}}/// summary/// 检查缓存是否存在/// /summarypublicboolExists(stringname){stringcacheKeythis.GetCacheKey(name);return_cacheProvider.Exists(cacheKey);}/// summary/// 获取缓存项不触发加载/// /summarypublicTEntityGet(stringname){stringcacheKeythis.GetCacheKey(name);if(_cacheProvider.Exists(cacheKey)){return_cacheProvider.GetTEntity(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 等动态实体publicabstractclassEntityCacheManagerTEntitywhereTEntity:IMapEntitystring{// 现有全部代码保持不变protectedabstractTEntityLoadFromFile(stringfilePath);// ...}2. 新增具体实现类用于静态实体publicclassStaticEntityCacheManagerTEntity:EntityCacheManagerTEntitywhereTEntity:IMapEntitystring,new(){privatereadonlyFuncstring,TEntity_loader;// 由调用方传入加载逻辑publicStaticEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider,Funcstring,TEntityloader):base(contentRootPath,cacheProvider){_loaderloader;}protectedoverrideTEntityLoadFromFile(stringfilePath){// 静态实体不需要从文件加载直接返回新实例或由调用方决定// 如果确实需要从文件加载可以用 _loader(filePath)returnnewTEntity();}}方案二将LoadFromFile改为虚方法非抽象publicclassEntityCacheManagerTEntitywhereTEntity:IMapEntitystring{// 改为虚方法默认实现返回 null但调用方需判断protectedvirtualTEntityLoadFromFile(stringfilePath){returndefault(TEntity);}privateTEntityLoadAndCache(stringname){stringfilePathGetFilePath(name);// ...TEntityentityLoadFromFile(filePath);if(entitynull){// 静态实体可在此处创建默认实例entityActivator.CreateInstanceTEntity();}// ...}}这样静态实体继承时不需要实现LoadFromFile但需要在LoadAndCache中处理null分支。方案三推荐独立出“实体工厂”接口将“如何获取实体”抽象为独立接口缓存管理器依赖此接口而非自身实现加载逻辑。publicinterfaceIEntityLoaderTEntitywhereTEntity:IMapEntitystring{TEntityLoad(stringidentifier);// identifier 可以是文件路径或名称}publicclassEntityCacheManagerTEntitywhereTEntity:IMapEntitystring{privatereadonlyIEntityLoaderTEntity_loader;publicEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider,IEntityLoaderTEntityloader){// ..._loaderloader;}privateTEntityLoadAndCache(stringname){// ...TEntityentity_loader.Load(filePath);// ...}}这样AnyORM提供XEntityLoader解析 配置静态实体提供StaticEntityLoaderreturn new TEntity()完全解耦无需修改基类您倾向哪种方案方案一保留抽象基类新增静态实体专用派生类。方案二将抽象方法改为虚方法默认返回默认值。方案三引入IEntityLoaderT接口彻底解耦。如果你让AI来选AI估计 选方案二AI生成代码就喜欢一步到位完成功能不考虑灵活复用性但主技术控来选很可能建议方案三因为它最灵活且符合开闭原则。读者有什么想法我说方案二耦合性太大方案三是过度设计我们搞ORM会只做动态、静态实体用方案一抽象基类派生最合适。用宝开源ORM是必须用DI吗前面说了应用程序启动时提供一个 builder.Services.AddSingletonICacheProvider, NullCacheProvider(); 注册以防止报错。因为我们继承EntityCacheManager的时候要注入ICacheProvider 的接口实例此时一个小技巧是发现使用者没有DI注册这时在构造函数注入的时候做一个判断以便引入一个默认什么也没有做的实例new NullCacheProvider()。/// summary/// XML 实体缓存管理器 —— 继承 EntityCacheManager专用于 XmlMapEntity/// 支持外部 ICacheProvider 和内部后备缓存内存字典双机制/// /summarypublicclassXmlEntityCacheManager:EntityCacheManagerXmlMapEntity{privatereadonlyXmlEntityParser_parser;privatereadonlyIDataDictionarystring,XmlMapEntity_fallbackCache;publicXmlEntityCacheManager(stringcontentRootPath,ICacheProvidercacheProvider,XmlEntityParserparser):base(contentRootPath,cacheProvider??newNullCacheProvider()){_parserparser??thrownewArgumentNullException(nameof(parser));_fallbackCachenewDataDictionarystring,XmlMapEntity();}}架构闭环用户请求 ↓ EntityCacheManager.GetOrLoad() ↓ 外部 ICacheProvider 存在且有效 ├── 是 → Redis/MemoryCache分布式、高可用、可观测 └── 否 → 内部内存字典零配置、单机、保运行 ↓ 返回模板 → 业务处理使用者没依赖注入上面说了使用都根本以为你这ORM是个最基本的东西根据没相到程序启动时要注册 但是你用new NullCacheProvider()其实什么也没做内部怎么处理其实外部没注册可以用 *内部内存字典_fallbackCache与真正的缓存实现ICacheProvider的核心差异维度内部内存字典Fallback真正的缓存实现ICacheProvider过期策略TTL❌ 无。永久驻留直到手动Refresh或重启应用。✅ 支持。SetT可指定TimeSpan绝对/滑动过期自动失效。内存管理❌ 无。字典会无限增长只增不减可能造成内存泄漏。✅ 有。如MemoryCache会按内存压力自动驱逐冷数据Redis有 LRU 策略。跨实例共享❌ 仅限当前进程。多服务器部署时各存各的浪费内存且不一致。✅ 可共享。如 Redis 支持分布式多服务器共用一份缓存。持久化❌ 进程重启即丢失。✅ 可持久化。Redis 支持 AOF/RDB重启不丢失。序列化❌ 直接存对象引用无需序列化快速但耦合。✅ 可支持跨进程序列化如 JSON/ProtoBuf适用于分布式。监控/统计❌ 无。✅ 可对接监控系统命中率、内存占用等。适用场景快速验证、单机部署、开发调试、容错兜底。生产环境、高并发、分布式集群、需要精细控制缓存策略。设计结论_fallbackCache的定位是“生存保障”用户不配缓存 → 能跑。用户缓存出问题 → 能跑。单机小应用 → 够用。ICacheProvider的定位是“性能与扩展”分布式多实例 → 共享缓存减少重复解析。高并发 → 缓存失效策略可控。生产环境 → 可观测、可调优。当前代码是“先外部后内部”的双层容错用户请求 → GetOrLoad() ↓ 外部 ICacheProvider 是否可用非 NullCacheProvider ├── 是 → 使用外部缓存高性能、分布式、可控 └── 否 → 自动降级到内部内存字典零配置、无感知、保运行这样设计既保证了“零配置开箱即用”又为高级用户保留了“可插拔高性能缓存”的扩展能力。符合框架“轻量、易用、不强制依赖”的定位。欢迎拷贝、转载无需授权反馈与交流欢迎在评论区留言或私信交流。如果你正在寻找一套不用 EF、不用 Dapper、可跨语言迁移的轻量级基架用宝框架或许是一个值得尝试的选择。用宝框架拥抱第一 · 一次书写 · 三端复用——不仅是用户的朋友而且是用户的宝贝