含关联属性对象与扁平化数据库对象的命名规范咨询

现有约定明确 #

约定说明：用Model表示与数据库表一一对应的扁平化映射对象，Dto表示数据传输对象。

现有问题梳理 #

当前采用CustomerAddressModel这类“基础模型+关联模型”的命名方式，当关联对象多达10个时，命名会极度冗长且难以维护；同时示例中用继承扩展关联模型的方式存在语义歧义（CustomerAddressModel并非一种CustomerModel，而是组合了两者的对象），还会引发字段冗余、逻辑混淆的问题。

可行命名方案推荐 #

方案1：后缀标识关联范围

• 基础模型保持原命名：CustomerModel（仅含表自身字段与外键ID）
• 包含关联的模型添加With[关联描述]后缀：
  • 仅关联地址：CustomerWithAddressModel
  • 关联地址+订单：CustomerWithAddressAndOrdersModel
  • 包含全量常用关联：CustomerWithRelatedModel
• 结构建议（优先组合而非继承）：

  public class CustomerWithAddressModel
  {
      public CustomerModel Customer { get; set; }
      public AddressModel Address { get; set; }
  }
  

• 优点：命名直观清晰，一眼可识别包含的关联对象，同时避免继承带来的耦合问题。

方案2：聚合根/组合语义命名

• 将包含关联的模型视为聚合对象，用Aggregate或Composite后缀区分：
  • 示例：CustomerAggregate、CustomerCompositeModel
• 结构示例：

  public class CustomerAggregate
  {
      public int CustomerID { get; set; }
      public string CustomerNumber { get; set; }
      public string CustomerGroup { get; set; }
      public AddressModel Address { get; set; }
      // 其他关联对象字段
  }
  

• 优点：明确传达“聚合多对象”的语义，适合有领域驱动设计倾向的团队。

方案3：结合SQLKata查询场景命名

• 针对SQLKata查询返回的组合结果，用QueryResult后缀标识：
  • 通用查询结果：CustomerQueryResultModel
  • 特定关联场景：CustomerWithAddressQueryResultModel、CustomerFullRelationsQueryResultModel
• 优点：与SQLKata的查询场景强绑定，清晰区分“表映射模型”和“查询结果模型”。

核心原则 #

避免用继承扩展关联模型，优先采用组合方式：继承表达“是”的语义，而含关联的对象是“包含”基础模型与关联对象的组合体，用组合能保持各模型职责单一，减少逻辑混淆。

内容的提问来源于stack exchange，提问作者Niels Lucas