C# Web API开发中有没有比Data Transfer Object更优的替代方案？

首先明确：DTO不是唯一可行方案，不过它是目前工业界公认的可维护性最高的主流实现。你提到的「违反DRY原则」属于对DRY的常见误解——DRY原则针对的是重复的业务逻辑，而非不同职责下的字段定义：TodoItem是绑定数据库结构的实体模型，TodoItemDTO是对外暴露的接口契约，二者职责完全独立，强行复用反而会导致数据层和接口层强耦合，后期迭代成本更高。

可选替代方案及优劣 #

• 方案1：实体模型加序列化/绑定忽略特性
  直接在TodoItem的机密字段上添加序列化忽略特性，返回给客户端时会自动跳过这些字段；同时添加绑定禁止特性避免过提交赋值：

  [JsonIgnore] // System.Text.Json序列化时忽略
  [BindNever] // 模型绑定时禁止前端传入赋值
  public string SecretField { get; set; }
  

  优点：无需新增类，无字段定义重复
  缺点：适配性极差，若存在多套接口需要返回不同字段组合（如普通用户/管理员接口返回字段不同）完全无法实现，且漏加特性就会导致机密字段泄露，安全风险高。

• 方案2：匿名类型返回
  接口返回时直接构造匿名对象，按需选取字段，无需单独定义DTO类：

  return Ok(_context.TodoItems.Select(x => new { x.Id, x.Name, x.IsComplete }));
  

  优点：写法灵活简便，无额外类维护成本
  缺点：无强类型约束，Swagger无法自动生成接口文档，单元测试、参数校验都难以实现，仅适合极小的内部临时项目使用。

• 方案3：DTO+自动映射库（主流推荐）
  保留DTO类做接口契约解耦，用AutoMapper、Mapster等自动映射库免除手动编写实体到DTO的赋值代码，仅需一行代码即可完成映射，既保留了DTO的解耦优势，又最大程度消除了重复代码。
  优点：完全解耦数据层和接口层，适配各种复杂的接口字段定制需求，可维护性和安全性都有保障
  缺点：需要引入第三方映射库，增加极少量的配置成本

选型建议 #

如果是临时用的微型项目、后续不会有迭代，可以选前两种方案快速实现；如果是需要长期维护的中大型项目，优先选择DTO+自动映射的方案，解耦带来的长期收益远高于重复定义几个字段的成本。

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