命名与数据转换规范

本页定义 C#、数据库和前端三套命名风格的正式约定，并解释这些命名在框架里如何转换。

适用场景

设计实体、DTO、请求响应对象和数据库对象。
处理 C#、Json 和数据库之间的字段映射。
审查项目是否混用了多套命名风格。

必须遵守

C# 类型、属性、DTO、Profile、Repository 等代码对象统一使用 PascalCase。
数据库表名、列名、审计字段统一使用 snake_case。
前端消费的 JSON 字段统一使用 camelCase。
同一概念在不同层保持同一根词，不因为层级不同改成不同业务名。
命名转换必须由统一配置、映射层或框架约定承担，不在控制器、页面和 SQL 片段里手工拼写多套命名。

推荐做法

数据库存储层使用框架或 ORM 的统一命名约定，例如 PostgreSQL 场景下的 UseSnakeCaseNamingConvention()。
C# 与数据库之间的特殊映射优先通过统一 Profile、配置类和 DTO 层处理。
前后端对接统一通过 Json 序列化配置保持 camelCase，避免前端自行兼容 PascalCase。
把审计字段、时间字段和并发字段的命名词典提前固定下来，减少跨模块漂移。

运作机制

C# 代码保持 PascalCase，因为这是 .NET 生态默认风格，便于阅读、反射和框架扫描。
PostgreSQL 数据库保持 snake_case，可以借助 UseSnakeCaseNamingConvention() 把代码命名和数据库命名的差异交给 ORM 统一处理。
Json 对外契约保持 camelCase，可以通过 JsonNetSerializerSettings.CamelCase 或等价全局配置统一转换。
框架还提供 PascalCaseToLowerUnderscoreProfile、LowerUnderscoreToPascalCaseProfile 等命名映射基类，适合在需要显式映射时复用。

常见问题

“为什么不直接让数据库也用 PascalCase？” 因为数据库、SQL 工具链和团队约定通常更适合 snake_case，同时框架已经提供了统一转换能力。
“前端能不能直接使用后端的 PascalCase 字段？” 不建议。这样会让 JavaScript 生态风格和接口契约不一致，长期成本更高。
“有了自动转换，是不是就不用关心命名了？” 不是。自动转换解决的是格式，不解决语义漂移。同一概念仍要保持同一根词。

相关检查

示例项目对照

woscm：UseSnakeCaseNamingConvention()、审计字段和版本字段命名清晰分离。
niusys-webapi：统一 Json 配置入口。
数据库命名主题：数据库命名侧的补充说明。