下栽地止：https://www.itwangzi.cn/2256.html
控制技术点
责任编辑不是两个诬蔑的该文，不会讲许多深奥的构架，恰好相反，会传授许多此基础的难题和读法难题，假如听众自认为此基础难题和读法难题都呢难题，那请忽视这首诗，节约出时间去做一些有象征意义的事。
如前所述 Spring Boot + MyBatis Plus + Vue & Element 同时实现的前台信息系统+ 使用者小流程，全力支持 RBAC 静态职权、多租客、统计数据职权、工作流、协力登入、缴付、手机短信、京东等机能。工程项目门牌号：https://github.com/YunaiV/ruoyi-vue-pro
应用软件
不晓得有啥”老”开发人员还在使用 Eclipse，这些开发人员们要不是固步自封，要不是显然就不晓得其他好的应用软件的存在，Eclipse 吃缓存雅雷的现像以及各式各样碰巧莫名其妙极度的出现，都知会我们是时候找寻捷伊应用软件了。
更改 IDE
显然就不该多说明没得怎样的 IDE，假如你想成为两个杰出的 Java 开发人员，请更改 IntelliJ IDEA。采用 IDEA 的益处，请搜寻Google。
别说我机能键不太好用
更改 IDE 无此我责任编辑的重点项目文本中，所以不该用太多的字数去写为何更改IDE。在这里，我根本无法说你，更改 IDE 只为了更快、更慢的写好 Java 标识符。其原因略。
别说我机能键不太好用，请试著新事物。
如前所述微服务项目的价值观，构筑在 B2C B2C情景下的工程项目两栖作战。关键控制技术栈，是 Spring Boot + Dubbo 。今后，会重形成 Spring Cloud Alibaba 。工程项目门牌号：https://github.com/YunaiV/onemall
Bean
bean 使我们采用最多的模型之一，我将以大字数去传授 bean，希望听众好好体会。
domain 包名
根据许多 Java 开发人员的”经验”来看，两个统计数据库表则对应着两个 domain 对象，所以许多开发人员在写标识符时，包名则采用：com.xxx.domain ，这样写好像已经成为了行业的一种约束，统计数据库映射对象就应该是 domain。但是你错了，domain 是两个领域对象，往往我们再做传统 Java 软件 Web 开发中，这些 domain 都是贫血模型，是没有行为的，或是没有足够的领域模型的行为的，所以，以这个理论来讲，这些 domain 都应该是两个普通的 entity 对象，并非领域对象，所以请把包名改为:com.xxx.entity。
假如你还不理解我说的话，请看一下 Vaughn Vernon 出的一本叫做《IMPLEMENTING DOMAIN-DRIVEN DESIGN》(同时实现领域驱动设计)这本书，书中传授了贫血模型与领域模型的区别，相信你会受益匪浅。
DTO
统计数据传输我们应该采用 DTO 对象作为传输对象，这是我们所约定的，因为很长时间我一直都在做移动端 API 设计的工作，有许多人说我，他们认为只有给手机端传输统计数据的时候(input or output)，这些对象成为 DTO 对象。请注意！这种理解是错误的，只要是用于网络传输的对象，我们都认为他们可以当做是 DTO 对象，比如B2C平台中，使用者进行下单，下单后的统计数据，订单会发到 OMS 或者 ERP 系统，这些对接的返回值以及入参也叫 DTO 对象。
我们约定某对象假如是 DTO 对象，就将名称改为 XXDTO，比如订单下发OMS：OMSOrderInputDTO。
DTO 转化
正如我们所知，DTO 为系统与外界交互的模型对象，那么肯定会有两个步骤是将 DTO 对象转化为 BO 对象或者是普通的 entity 对象，让 service 层去处理。
情景
比如添加会员操作，由于用于演示，我只考虑使用者的一些简单统计数据，当前台管理员点击添加使用者时，只需要传过来使用者的姓名和年龄就可以了，后端接受到统计数据后，将添加创建时间和更新时间和默认密码三个字段，然后保存统计数据库。
@RequestMapping(“/v1/api/user”)@RestControllerpublicclassUserApi{@Autowiredprivate UserService userService;@PostMappingpublic User addUser(UserInputDTO userInputDTO){ User user = new User(); user.setUsername(userInputDTO.getUsername()); user.setAge(userInputDTO.getAge());return userService.addUser(user);}}
User user = new User();user.setUsername(userInputDTO.getUsername());user.setAge(userInputDTO.getAge());
请采用工具
上边的标识符，从逻辑上讲，是没有难题的，只是这种读法让我很厌烦，例子中只有两个字段，假如有20个字段，我们要如何做呢？两个两个进行 set 统计数据吗？当然，假如你这么做了，肯定不会有什么难题，但是，这肯定不是两个最优的做法。
网上有许多工具，全力支持浅拷贝或深拷贝的 Utils。举个例子，我们可以采用 org.springframework.beans.BeanUtils#copyProperties 对标识符进行重构和优化：
@PostMappingpublic User addUser(UserInputDTO userInputDTO){ User user = new User(); BeanUtils.copyProperties(userInputDTO,user);return userService.addUser(user);}
BeanUtils.copyProperties 是两个浅拷贝方法，复制属性时，我们只需要把 DTO 对象和要转化的对象两个的属性值设置为一样的名称，并且保证一样的类型就可以了。假如你在做 DTO 转化的时候一直采用 set 进行属性赋值，那么请试著这种方式简化标识符，让标识符更加清晰!
转化的语义
上边的转化过程，听众看后肯定觉得优雅许多，但是我们再写 Java 标识符时，更多的需要考虑语义的操作，再看上边的标识符：
User user = new User();BeanUtils.copyProperties(userInputDTO,user);
虽然这段标识符很好的简化和优化了标识符，但是他的语义是有难题的，我们需要提现两个转化过程才好，所以标识符改成如下：
@PostMappingpublic User addUser(UserInputDTO userInputDTO){ User user = convertFor(userInputDTO);return userService.addUser(user);}private User convertFor(UserInputDTO userInputDTO){ User user = new User(); BeanUtils.copyProperties(userInputDTO,user);return user;}
这是两个更快的语义读法，虽然他麻烦了些，但是可读性大大增加了，在写标识符时，我们应该尽量把语义层次差不多的放到两个方法中，比如：
User user = convertFor(userInputDTO);return userService.addUser(user);
这两段标识符都没有暴露同时实现，都是在讲如何在同两个方法中，做一组相同层次的语义操作，而不是暴露具体的同时实现。
如上所述，是一种重构方式，听众可以参考 Martin Fowler 的《Refactoring Imporving the Design of Existing Code》(重构改善既有标识符的设计)这本书中的 Extract Method 重构方式。
抽象接口定义
当实际工作中，完成了几个 API 的 DTO 转化时，我们会发现，这样的操作有许多许多，那么应该定义好两个接口，让所有这样的操作都有规则的进行。
假如接口被定义以后，那么 convertFor 这个方法的语义将产生变化，它将是两个同时实现类。
看一下抽象后的接口：
