download: 微体系 - 多端全栈我的项目实战：商业级代驾全流程落地完结无密
导语
自从毕业后，往年曾经是我工作的第 8 个年头了，我甚至都快遗记了到底是哪年毕业的。
从进去，自己始终在做 Java 相干的工作，当初终于有工夫坐下来，写一篇对于 Java 写法的一篇文章，来探讨一下如果你真的是一个 Java 程序员，那你真的会写 Java 吗？
笔者是一个求实的程序员，故本文绝非扯淡文章，文中内容都是干货，望读者看后，能有所播种。
本文不是一个吹牛的文章，不会讲很多浅近的架构，相同，会解说很多根底的问题和写法问题，如果读者自认为根底问题和写法问题都是不是问题，那请疏忽这篇文章，节俭出工夫去做一些有意义的事件。
开发工具
不晓得有多少“老”程序员还在应用 Eclipse，这些程序员们要不就是旧调重弹，要不就是基本就不晓得其余好的开发工具的存在，Eclipse 吃内存卡顿的景象以及各种偶尔莫名异样的呈现，都告知咱们是时候寻找新的开发工具了。
| 更换 IDE
基本就不想多解释要换什么样的 IDE，如果你想成为一个优良的 Java 程序员，请更换 IntelliJ IDEA。应用 IDEA 的益处，请搜寻谷歌。
| 别通知我快捷键不好用
更换 IDE 不在我本文的重点内容中，所以不想用太多的篇幅去写为什么更换 IDE。在这里，我只能通知你，更换 IDE 只为了更好、更快的写好 Java 代码。起因略。
别通知我快捷键不好用，请尝试新事物。
| 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 对象，比方电商平台中，用户进行下单，下单后的数据，订单会发到 OMS 或者 ERP 零碎，这些对接的返回值以及入参也叫 DTO 对象。
咱们约定某对象如果是 DTO 对象，就将名称改为 XXDTO，比方订单下发 OMS：OMSOrderInputDTO。
| DTO 转化
正如咱们所知，DTO 为零碎与外界交互的模型对象，那么必定会有一个步骤是将 DTO 对象转化为 BO 对象或者是一般的 entity 对象，让 service 层去解决。
| 场景
比方增加会员操作，因为用于演示，我只思考用户的一些简略数据，当后盾管理员点击增加用户时，只须要传过来用户的姓名和年龄就能够了，后端承受到数据后，将增加创立工夫和更新工夫和默认明码三个字段，而后保留数据库。
@RequestMapping(“/v1/api/user”)
@RestController
public class UserApi {
@Autowired
private UserService userService;
@PostMapping
public 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 对代码进行重构和优化：
@PostMapping
public 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);