关于DTO的定义问题。以及C#语言扩展的思考。
数据传输对象 是我们经常用到的一个东西。有时候我们称之为的ViewModel也属于其中之一。
但是以往,我们总是 复制 实体类型的一些字段 然后单独创建这些对象。然后我们使用对象映射工具 进行值层面的映射比如AutoMapper。
我感觉 DTO只是对实体或者持久化数据的引用及扩展
而我们现在定义了太多的 对象。一遍又一遍地从实体copy出需要的字段 变成DTO,但是随着业务的变化,改进和迭代,涉及到实体以及众多的DTO的修改,让我们的维护也变得更加困难(分散的,改了一个地方要改很多地方,而且有时候难免漏掉造成bug)。
这严重违反了DRY 原则
下面我们看下一个新的定义方式:
class Entity{
string Name;
NewCmd:Entity|CreateDate:DBDate()
SearchQuery:Entity(!Name)|Key:DBText(20)|
bool Create(NewCmd newcmd){....}
bool Query(SearchQuery newcmd){....}
}
NewCmd 继承了 Entity的所有字段,并且扩展了一个CreateDate字段。
SearchQuery 继承了 Entity中除了Name之外的所有字段,并且扩展了一个Key字段。
应该说这样的DTO逻辑一目了然,最重要的是当底层 Entity修改的时候。我们的DTO也随之修改了。
所以 DTO在语义上 应该 是对持久化实体的引用和扩展
可以屏蔽某些字段也可以扩展某些字段
这样 就舒服了
但是这需要语言层面的支持
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· AI 智能体引爆开源社区「GitHub 热点速览」
· 从HTTP原因短语缺失研究HTTP/2和HTTP/3的设计差异
· 三行代码完成国际化适配,妙~啊~