MyFramework 里有一套自己的表格工具链。有人可能会问既然已经有 Luban 这种成熟的配置表工具为什么 MyFramework 里还要保留自己的表格工具先说结论MyFramework 的表格工具不是为了替代 Luban。Luban 是一个通用配置表解决方案目标是服务不同项目、不同语言、不同引擎、不同数据格式。它官方介绍里也强调了数据校验、跨平台、主流引擎和热更新方案支持等能力。MyFramework 的表格工具则不是通用工具。它更像是项目内部的一套配置生产线。它服务的是 MyFramework 自己的工程结构Unity 客户端C 服务器CSV 配置表自研表格编辑器客户端代码生成服务器代码生成资源路径检查表格引用检查项目工程检查运行时数据检查项目地址https://github.com/ZHOURUIH/MyFramework这篇文章不是要讨论谁更强而是说清楚通用配置表工具和项目内表格工具链到底有什么区别。一、定位不同Luban 的定位是通用配置表解决方案。它要解决的是各种游戏项目都会遇到的配置问题表格怎么定义数据怎么校验代码怎么生成多语言怎么支持多引擎怎么接入多种数据格式怎么导出客户端和服务器怎么共用配置所以 Luban 更像一个标准化配置基础设施。它适合很多项目使用。MyFramework 的表格工具定位更窄。它不是为了适配所有项目而是为了服务自己的项目结构。我的项目里配置表不是一个孤立工具而是和框架里的其他系统绑定在一起资源管理热更新代码结构服务器框架协议生成工程检查运行时配置加载AssetBundle 构建规则所以 MyFramework 的表格工具更像框架内部工作流的一部分。Luban 解决的是如何给各种项目提供一套通用配置表方案。MyFramework 解决的是如何让自己的项目从表格编辑、检查、生成到运行时使用都形成闭环。这是最核心的区别。二、MyFramework 的表格不是只生成数据类MyFramework 的表格代码里生成结果不是只有一个数据类。它大致会分成两层EDXXX一行配置数据ExcelXXX一张表的管理、查询、检查和扩展逻辑比如怪物表的数据类是EDMonster。它是自动生成的// auto generate start using System; using System.Collections.Generic; using UnityEngine; // 怪物细分表 public class EDMonster : ExcelData { public static int WORLD_BOSS_ID 370; // 世界boss-火焰巨神 public static EDMonster WORLD_BOSS; // 世界boss-火焰巨神 public string mName; // 怪物名字 public ushort mTemplateID; // 怪物模板ID,索引到MonsterTemplate表 public MONSTER_STRENGTH mStrengthType; // 怪物强度类型 public ushort mLevel; // 怪物等级 public int mHP; // 怪物血量 public ushort mMoveSpeed; // 怪物闲逛时的移动速度 public Listushort mSkill new(); // 怪物技能列表 public Listushort mTelentBuff new(); // 怪物天赋buff public ushort mDisplayOrderID; // 在怪物图鉴中显示的顺序 public string mCustomNameColor; // 自定义的怪物名称颜色,如果设置了自定义颜色,将会覆盖怪物强度等级的颜色 public int mShowSound; // 出现在屏幕中时播放的音效 public float mShowSoundOdds; // 播放出现音效的几率这里可以看到生成代码不是简单把 CSV 原样读出来。它已经转换成了项目里可以直接使用的强类型字段。比如mTemplateIDmStrengthTypemSkillmTelentBuffmShowSound这些字段和项目里的枚举、技能表、Buff 表、音效表都有关系。这就是 MyFramework 的特点。表格不是孤立的数据文件。表格字段天然会和项目里的其他系统发生关系。三、读取逻辑也是生成出来的EDMonster里不只是字段还会生成读取逻辑。例如public override bool read(SerializerRead reader) { bool result base.read(reader); result result reader.readString(out mName); result result reader.read(out mTemplateID); result result reader.readEnumByte(out mStrengthType); result result reader.read(out mLevel); result result reader.read(out mHP); result result reader.read(out mMoveSpeed); result result reader.readList(mSkill); result result reader.readList(mTelentBuff); result result reader.read(out mDisplayOrderID); result result reader.readString(out mCustomNameColor); result result reader.read(out mShowSound); result result reader.read(out mShowSoundOdds); return result; }这段代码说明一个事情MyFramework 的表格工具不是在运行时通过反射或动态字段名去读数据。它会生成明确的读取代码。字段是什么类型就调用对应的读取接口。比如字符串走readString枚举走readEnumByte列表走readList普通数值走read这样做的好处是运行时更直接。缺点是生成器和项目框架绑定更深。这也是 MyFramework 和 Luban 的区别之一。Luban 更强调通用配置生成能力。MyFramework 更强调生成结果和自己运行时框架的配合。四、表格注册也进入框架流程MyFramework 里所有表都会进入统一注册流程。比如ExcelRegister里会生成这样的注册代码public class ExcelRegister { public static void registeAll() { registeTable(out mExcelAchivement, typeof(EDAchivement), Achivement); registeTable(out mExcelAnimation, typeof(EDAnimation), Animation); registeTable(out mExcelBuff, typeof(EDBuff), Buff); registeTable(out mExcelBuffDetail, typeof(EDBuffDetail), BuffDetail); registeTable(out mExcelCondition, typeof(EDCondition), Condition); registeTable(out mExcelEffect, typeof(EDEffect), Effect); registeTable(out mExcelMonster, typeof(EDMonster), Monster); registeTable(out mExcelMonsterSkill, typeof(EDMonsterSkill), MonsterSkill); registeTable(out mExcelMonsterTemplate, typeof(EDMonsterTemplate), MonsterTemplate); registeTable(out mExcelSound, typeof(EDSound), Sound); // 进入热更以后,所有资源都处于可用状态 mExcelManager.resourceAvailable(); } protected static void registeTableT(out T table, Type dataType, string tableName) where T : ExcelTable { table mExcelManager.registe(tableName, typeof(T), dataType) as T; } }这里能看到MyFramework 的表格并不是各自独立加载。所有表都会注册到mExcelManager。注册时会带上表名表类型数据类型比如怪物表注册的是registeTable(out mExcelMonster, typeof(EDMonster), Monster);这意味着表格系统天然接入了框架的全局管理流程。这和通用导表工具的关注点不一样。Luban 更关心怎么生成不同项目都能使用的配置代码。MyFramework 更关心这些表怎么进入自己的框架生命周期。五、MyFramework 的表格类可以手写扩展这一点很重要。MyFramework 生成的数据类是EDXXX。但表管理类是ExcelXXX而且很多表类是partial。比如怪物表public partial class ExcelMonster : ExcelTableTEDMonster { protected ListEDMonster mPreviewMonsterList; public int getMonsterCount() { if (mPreviewMonsterList null) { initMonsterList(); } return mPreviewMonsterList.Count; } public ListEDMonster getPreviewMonsterList() { if (mPreviewMonsterList null) { initMonsterList(); } return mPreviewMonsterList; } }这部分就不是单纯的导表代码了。它已经开始进入项目业务逻辑。比如怪物图鉴需要一份可预览怪物列表表格类里就可以增加缓存列表排序逻辑分页获取逻辑过滤逻辑怪物图鉴列表的初始化也直接写在表类里protected void initMonsterList() { if (mPreviewMonsterList ! null) { return; } mPreviewMonsterList new(); // 删除所有不需要出现在图鉴中的怪物 foreach (EDMonster item in queryAll()) { mPreviewMonsterList.addIf(item, item.mDisplayOrderID 0); } // 根据顺序排序 mPreviewMonsterList.Sort((a, b) { return sign(a.mDisplayOrderID - b.mDisplayOrderID); }); }这就是 MyFramework 的项目化特点。表格类不只是“数据容器”。它也可以承载和这张表强相关的查询、缓存、排序、检查逻辑。这类设计不一定适合通用工具。但在自己的项目里很方便。因为很多表都有自己的业务查询方式。如果全部放到外部系统里反而会分散。六、检查逻辑可以分成默认生成和手写补充MyFramework 里表格检查不是一个统一的外部规则列表。它会生成默认检查也允许手写补充检查。比如ExcelMonster里有手写检查public override void checkAllData() { base.checkAllData(); foreach (EDMonster item in queryAll()) { mExcelMonsterTemplate.checkData(item.mTemplateID, item.mID, this); mExcelMonsterSkill.checkData(item.mSkill, item.mID, this); mExcelBuffDetail.checkData(item.mTelentBuff, item.mID, this); } }它还会生成默认检查// auto generate start protected override void checkAllDataDefault() { foreach (EDMonster item in queryAll()) { mExcelMonsterTemplate.checkData(item.mTemplateID, item.mID, this); checkEnum(item.mStrengthType, mStrengthType, item.mID); mExcelMonsterSkill.checkData(item.mSkill, item.mID, this); mExcelBuffDetail.checkData(item.mTelentBuff, item.mID, this); mExcelSound.checkData(item.mShowSound, item.mID, this); } } protected override void postParseFile() { EDMonster.postLoadAll(this); } // auto generate end这段代码很能体现 MyFramework 表格工具的特点。它不是只生成字段。它还会根据字段关系生成检查逻辑。比如mTemplateID要检查MonsterTemplate表mStrengthType要检查枚举是否合法mSkill要检查MonsterSkill表mTelentBuff要检查BuffDetail表mShowSound要检查Sound表这就是项目内表格工具的价值。表格字段不是孤立字段。字段背后有项目关系。MyFramework 的生成器会把这些项目关系也生成到检查流程里。七、Luban 的检查更通用MyFramework 的检查更项目化Luban 也有很强的数据校验能力。比如官方文档里就有ref引用检查、path资源路径检查、range范围检查等校验器。但 Luban 的检查更偏通用。它需要适配各种项目。MyFramework 的检查更偏项目化。比如这段mExcelMonsterTemplate.checkData(item.mTemplateID, item.mID, this); mExcelMonsterSkill.checkData(item.mSkill, item.mID, this); mExcelBuffDetail.checkData(item.mTelentBuff, item.mID, this); mExcelSound.checkData(item.mShowSound, item.mID, this);这不是抽象的“引用检查”。它直接就是项目里的表引用关系。怪物表引用怪物模板表。怪物表引用怪物技能表。怪物表引用 BuffDetail 表。怪物表引用 Sound 表。这种检查和项目强绑定。优点是检查很直接问题定位也很直接。缺点是通用性不高。但 MyFramework 本来就不是要做一个通用导表器。它要解决的是自己项目里的真实问题。八、数据后处理也进入表格流程EDMonster里还有一个后处理函数public static void postLoadAll(ExcelTableTEDMonster table) { WORLD_BOSS table.query(WORLD_BOSS_ID); }而ExcelMonster里生成的postParseFile会调用它protected override void postParseFile() { EDMonster.postLoadAll(this); }这说明 MyFramework 的表格加载流程不只是读取文件生成对象放进字典它还会有表级别的后处理。比如这里把世界 Boss 的配置缓存成静态对象public static EDMonster WORLD_BOSS;这类需求在项目里很常见。某些全局配置、特殊 ID、常用数据需要在加载后直接缓存起来。通用导表工具当然也可以做后处理。但 MyFramework 的特点是这个后处理流程已经是表格体系的一部分。它和生成代码、表格注册、数据检查都在同一个工作流里。九、MyFramework 更强调客户端和服务器配套Luban 支持多语言、多平台这是它的优势。MyFramework 不追求支持那么多语言。我的目标更明确Unity 客户端生成 C# 表格代码C 服务器生成对应表格代码客户端和服务器使用同一套配置定义字段、ID、枚举、引用关系保持一致这和 MyFramework 的定位有关。MyFramework 不是一个单独客户端框架。它还有配套服务器框架https://github.com/ZHOURUIH/MyServerFramework所以表格工具必须考虑客户端和服务器协作。Luban 是多语言通用生成。MyFramework 是客户端和服务器项目配套生成。这个目标更窄但和我的项目更贴合。十、为什么我没有直接换成 LubanLuban 很成熟也很强。如果一个项目需要的是成熟通用导表方案Luban 很合适。尤其是这些情况需要多语言代码生成需要复杂类型系统需要多种数据源格式需要多种导出格式不想自己维护导表工具希望配置工作流标准化项目跨多个引擎或多个运行环境但 MyFramework 的表格工具已经和项目流程绑得很深。它不仅负责生成数据类还负责注册表格接入 ExcelManager生成读取逻辑生成默认检查逻辑保留手写扩展逻辑做表之间的引用检查做枚举检查做后处理和客户端服务器流程配套这些东西不是不能用 Luban 实现。而是如果换成 Luban我仍然需要在外面再包一层项目规则。既然这套项目规则已经在 MyFramework 里跑通那保留自己的表格工具链就有意义。所以我的选择不是因为 Luban 不好。而是因为 MyFramework 的表格工具已经是项目内部生产线的一部分。十一、适合场景不同Luban 更适合这些项目希望使用成熟通用配置方案需要多语言代码生成需要多种数据源格式需要多种导出格式需要复杂类型系统不想自己维护导表工具希望配置流程标准化项目可能跨 Unity、Unreal、服务器、多语言环境MyFramework 的表格工具更适合这些情况已经使用 MyFramework客户端是 Unity服务器使用配套 C 框架表格格式希望统一更重视项目内检查希望和资源管理联动希望和协议生成联动希望和工程检查工具联动希望表格类可以写项目扩展逻辑希望工具链完全按自己的项目习惯定制所以这两个工具不是替代关系。Luban 更适合标准化通用配置流程。MyFramework 的表格工具更适合自己的框架体系。总结MyFramework 的表格工具和 Luban 最大的区别不在于某个功能点谁多谁少。而在于定位不同。Luban 是一个更通用、更完整的游戏配置解决方案。它适合各种项目、各种语言、各种数据格式也适合希望使用成熟导表工具的团队。MyFramework 的表格工具则是一个更项目化、更框架内聚的配置工作流。从代码上也能看出来EDMonster负责一行数据结构和读取ExcelMonster负责表级逻辑、查询缓存、数据检查和后处理ExcelRegister负责把所有表注册进mExcelManagercheckAllDataDefault负责生成默认表引用和枚举检查checkAllData可以继续补项目手写检查postParseFile可以做表加载后的后处理所以 MyFramework 的表格工具不是单纯导表器。它更像项目内部生产线的一部分。我的理解是Luban 更像标准化配置基础设施。MyFramework 的表格工具更像项目内部生产线。标准化工具适合解决通用问题。项目内部生产线适合解决自己项目里的具体问题。这就是我在 MyFramework 里保留自研表格工具链的原因。