mirror of
https://github.com/GeWuYou/GFramework.git
synced 2026-05-07 00:39:00 +08:00
docs(game): 同步生成器与持久化入口配置边界
- 补充 Game.SourceGenerators 对共享 schema 子集的 reader-facing 采用边界说明 - 更新 serialization 与 storage 页面中的复杂 schema 回退路径提示 - 明确 oneOf、anyOf 与非 false additionalProperties 不属于默认采用路径
This commit is contained in:
parent
7e62313b24
commit
e8203bc76e
@ -14,6 +14,9 @@
|
||||
- 对应的表包装类型
|
||||
- 与 `GFramework.Game.Config` 运行时协作的访问辅助代码
|
||||
|
||||
这里要先明确一条采用边界:`GFramework.Game.SourceGenerators` 服务的是当前与 `GFramework.Game`
|
||||
Runtime 对齐的共享 schema 子集,而不是任意 `JSON Schema` 的全量实现。它的目标是让配置生成、运行时校验和工具链维持同一份可落地契约,而不是把所有 schema 组合能力都映射成生成类型。
|
||||
|
||||
## 包关系
|
||||
|
||||
- 运行时:`GFramework.Game`
|
||||
@ -73,6 +76,15 @@ GameProject/
|
||||
- 你希望在编译期拿到强类型配置访问入口
|
||||
- 你希望运行时加载、schema 校验和编辑工具链共用同一份结构定义
|
||||
|
||||
如果你的 schema 设计依赖下面这些场景,就不属于当前默认采用路径:
|
||||
|
||||
- `oneOf`
|
||||
- `anyOf`
|
||||
- 非 `false` 的 `additionalProperties`
|
||||
- 其他依赖开放对象形状、联合分支或属性合并的复杂组合约束
|
||||
|
||||
遇到这些情况时,建议先回到 [配置系统文档](../docs/zh-CN/game/config-system.md) 和原始 schema / YAML 设计本体,确认是否需要调整配置建模方式,而不是默认期待生成器直接支持完整 `JSON Schema` 语义。
|
||||
|
||||
## 对应文档
|
||||
|
||||
- 配置系统:[配置系统文档](../docs/zh-CN/game/config-system.md)
|
||||
|
||||
@ -148,11 +148,14 @@ var restored = serializer.Deserialize(json, data.GetType());
|
||||
|
||||
如果你的目标是静态内容配置表,而不是运行时持久化对象,请改看 [配置系统](./config-system.md)。
|
||||
|
||||
如果你在配置系统里进一步碰到更复杂的 schema shape,也要尽快回到配置系统主文档和 raw YAML / schema 本体继续设计。当前默认采用路径面向的是与 `GFramework.Game` Runtime 和 `Game.SourceGenerators` 对齐的共享 schema 子集,不是任意 `JSON Schema` 的全量支持。
|
||||
|
||||
## 当前边界
|
||||
|
||||
- 当前公开默认实现只有 JSON,没有内建 MessagePack、Binary 或 ProtoBuf 实现
|
||||
- `JsonSerializer` 负责序列化,不负责对象版本迁移;版本迁移属于 `SettingsModel<TRepository>` 或 `SaveRepository<TSaveData>`
|
||||
- 序列化器共享后应视为只读配置对象,避免在运行期继续修改 settings / converters
|
||||
- 如果配置设计依赖 `oneOf`、`anyOf`、非 `false` 的 `additionalProperties`,或其他需要开放对象形状与联合分支的复杂约束,请直接按配置系统主文档回到 raw YAML / schema 方案处理,而不是把这些场景归到序列化层
|
||||
|
||||
## 继续阅读
|
||||
|
||||
|
||||
@ -165,6 +165,8 @@ var cacheStorage = new ScopedStorage(rootStorage, "runtime-cache");
|
||||
- 业务层如果想保存设置,可继续阅读 [设置系统](./setting.md)
|
||||
- 业务层如果只是需要底层存储实现,才直接依赖 `IStorage`
|
||||
|
||||
如果你是在“配置系统最终把内容保存到哪里”这个角度读到这里,需要先把边界分开:`IStorage` 负责运行时持久化,不负责定义配置 schema 的支持范围。配置工作流里只要开始出现更复杂的 schema shape,仍应先回到 [配置系统](./config-system.md) 和 raw YAML / schema 本体继续设计,再决定运行时是否需要额外存储落盘策略。
|
||||
|
||||
## 当前边界
|
||||
|
||||
- `FileStorage` 已经会通过注入的 `ISerializer` 自动序列化对象;默认接法不需要先手工 `Serialize(...)` 再把字符串写回
|
||||
@ -172,6 +174,7 @@ var cacheStorage = new ScopedStorage(rootStorage, "runtime-cache");
|
||||
- `ScopedStorage` 只做 key 前缀,不做权限、事务或迁移控制
|
||||
- 锁粒度是“当前实例内的目标路径”,不是跨进程文件锁
|
||||
- 原子写入只覆盖单文件替换,不等于多文件事务
|
||||
- 如果配置建模依赖 `oneOf`、`anyOf`、非 `false` 的 `additionalProperties`,或其他超出当前共享 schema 子集的复杂组合约束,这不是 `IStorage` 层能放宽的限制;应直接回到配置系统主文档与 raw YAML / schema 设计处理
|
||||
|
||||
## 继续阅读
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user