1.之前自己写的项目中的:
前台<–>controller<–>service<—>dao<—实体类POJO–>数据库
之前自己的项目中,数据的传递都是通过POJO实体类的方式来在不同层中传递。这样的缺点是:传递的数据过多,影响效率,并且容易暴露数据库的表结构;在微服务的企业级项目中,不易于客户的自定义需求以及项目的开发和维护。
2.实际项目中使用的:
前台<–通过VO–>controller<–通过DTO–>service<—>dao<—entity–>数据库
entity类中的属性是和数据库中的列一一对应的,DTO类中则是经过逻辑处理的部分属性,最后VO类中则是最后显示到前台中的数据属性(VO里
可以放entity也可以放list包括List<Entity>、list<Dto>还有其他dto)
PS:
项目中,在@FeignClient(value = "saasplatform-masterdata",fallback =MasterDataFeignClientFallback.class)注解的接口中,接口方法的返回值类型为:VO

而对应的服务中的实现类的返回值类型:DTO

总结:
被调用的服务中的实现类返回值类型DTO,它其中包含的属性比VO中多,通过服务调用,尽管类型不一致,但会自动将DTO中与VO属性名称相同的复制过去,舍弃了前台不需要展示的属性。
本文对比分析了传统POJO实体类与现代VO、DTO在前后端数据交互中的应用,阐述了VO、DTO如何提高微服务项目开发效率及客户定制能力,减少数据冗余,提升系统维护性。
727

被折叠的 条评论
为什么被折叠?



