通用本地化数据建模方案咨询（Backend API+Angular前端）

我需要开发两个涉及本地化的项目：Backend API（基于C#，负责MongoDB的CRUD操作）和Angular前端（用于编辑/创建本地化内容）。现需设计通用的数据建模方案，当前数据示例如下：

{
  "tabs": {
    "overview": "Overview",
    "schedule": "Schedule",
    "insights": "Insights",
    "settings": "Settings",
    "presets": "Presets"
  },
  "general": {
    "edit": "Edit",
    "bluetooth": {
        "activate": "activation",
        "test": "testing"
     }
  }
}

数据支持嵌套结构（如示例中的bluetooth），且会随应用本地化需求持续扩展。我当前设想的模型如下：

public string Category { get; set; }
public Dictionary<string, object> Translation { get; set; }

不确定该方案是否为最优选择，寻求更好的替代方案。

你的初始方案能满足基本需求，但在类型安全性、查询效率和前端编辑体验上有优化空间，以下是几个更实用的替代方案：

1. 扁平化键值对模型（推荐用于查询优先场景） #

将嵌套结构转为带路径的扁平键，比如general.bluetooth.activate作为键，直接存储翻译值，模型如下：

public string Key { get; set; } // 示例值: "tabs.overview", "general.bluetooth.activate"
public string LanguageCode { get; set; } // 比如 "en-US", "zh-CN"
public string Value { get; set; }

• 优点：MongoDB查询、更新单个翻译项效率极高；类型安全，前端编辑时结构清晰；易于扩展多语言。
• 缺点：失去了原有的层级结构，需要前端/后端自行处理路径的解析与拼接。

2. 强类型嵌套模型（推荐用于结构相对稳定的场景） #

如果本地化内容的层级结构不会频繁大幅变动，可以定义强类型的嵌套类：

public class LocalizationEntry
{
    public string Category { get; set; }
    public string LanguageCode { get; set; }
    public TabsTranslations Tabs { get; set; }
    public GeneralTranslations General { get; set; }
}

public class TabsTranslations
{
    public string Overview { get; set; }
    public string Schedule { get; set; }
    // 其他tab字段...
}

public class GeneralTranslations
{
    public string Edit { get; set; }
    public BluetoothTranslations Bluetooth { get; set; }
}

public class BluetoothTranslations
{
    public string Activate { get; set; }
    public string Test { get; set; }
}

• 优点：完全的类型安全，编译期就能发现错误；后端处理逻辑更直观。
• 缺点：结构变动时需要修改模型并重新部署，灵活性不足，不适合频繁扩展的场景。

3. 混合结构模型（平衡灵活性与类型安全） #

保留Category，同时用Dictionary<string, object>存储嵌套结构，但额外加入LanguageCode字段支持多语言：

public class LocalizationDocument
{
    public string Category { get; set; }
    public string LanguageCode { get; set; }
    public Dictionary<string, object> Translations { get; set; }
}

• 优点：继承了你初始方案的灵活性，同时支持多语言隔离；可以通过MongoDB的点语法查询嵌套字段（比如Translations.general.bluetooth.activate）。
• 缺点：object类型会导致C#中处理嵌套值时需要频繁类型转换，前端编辑时也需要额外处理数据类型判断。

4. 使用MongoDB的BSON文档类型 #

直接利用MongoDB的BSON特性，用BsonDocument替代Dictionary<string, object>：

public string Category { get; set; }
public string LanguageCode { get; set; }
public BsonDocument Translations { get; set; }

• 优点：完全适配MongoDB的嵌套结构，支持所有BSON类型；查询和更新嵌套字段更高效。
• 缺点：C#中处理BsonDocument的学习成本略高，前端需要转换为JSON格式使用。

方案选择建议 #

• 如果你的本地化内容需要频繁扩展结构，优先选扁平化键值对模型或混合结构模型。
• 如果结构相对固定，追求类型安全和开发效率，选强类型嵌套模型。
• 如果重度依赖MongoDB的原生特性，选BSON文档类型。

内容的提问来源于stack exchange，提问作者Emirhan Demirci