前言
会用与灵活的用好之间是妙之巅豪,失之千里。小细节大管理与大效率,管理没有大小之分, 很小的细节管理可能会很大在个个方面提升效率,降低成本。本章节是鸟菜啊在多年开发中一直使用的规则。方法(借口)行参与返回只用实体类
说一个真实的故事
刚刚到一个新小组,在一次会议的时候。
鸟菜啊:以后所有的方法(接口)行参与返回只用实体类
老员工A说:这不是增加了很多工作量吗?
新员工B说:是啊,很麻烦啊。
鸟菜啊:就这样定了,先执行吧。
..... 很久之后,老员工A去其他小组了
某天
老员工A对其他人说:方法(接口)行参与返回要用实体类
鸟差啊听了哈哈大笑
好处
- 保持接口的单一性与向前兼容
- 减少维护工作量
- 介绍沟通成本
保持接口的单一性
第一阶段 只需要通过用户id查询用户信息
public class UserController{
public UserInfo getUserInfo(Long userId){
}
}
第二阶段需求 需要通过 userId 与 appId 得到用户
public class UserController{
@RequestMapping("getUserInfo")
public UserInfo getUserInfo(Long userId ){
}
@RequestMapping("newGetUserInfo")
public UserInfo getUserInfo(Long userId , Long appId){
}
}
- 如果为了保持向前兼容需要保留以前的方法,在添加新方法。同时需要维护两个接口,还需要与其他人通过新接口,成本增大。
- 如果不新增接口,那么 getUserInfo(Long userId , Long appId)需要同时处理UserId与 UserId和AppId的行为,那么对接方需要全部修改,影响人数太多了。
如果使用实体类
第一阶段 只需要通过用户id查询用户信息
public class UserController{
public UserInfo getUserInfo(UserInfo userInfo){
}
}
第二阶段需求 需要通过 userId 与 appId 得到用户
public class UserController{
public UserInfo getUserInfo(UserInfo userInfo){
}
}
接口的定义与声明根本就没有发生变化,
减少维护工作量
public class UserController{
public UserInfo getUserInfo(Long userId){
}
}
public Implementation UserServer{
public UserInfo getUserInfo(Long userId);
}
public class UserServerImpl Implementation UserServer{
public UserInfo getUserInfo(Long userId);
}
public class UserDao{
public UserInfo getUserInfo(Long userId);
}
当发生修改的时候
public class UserController{
public UserInfo getUserInfo(Long userId , AppId appId){
userServer.getUserInfo( userId , appId);
}
}
public Implementation UserServer{
public UserInfo getUserInfo(Long userId , AppId appId);
}
public class UserServerImpl Implementation UserServer{
public UserInfo getUserInfo(Long userId , AppId appId){
return userDao.getUserInfo( userId , appId)
}
}
public class UserDao{
public UserInfo getUserInfo(Long userId , AppId appId);
}
需要找到每个接口与类,打开,修改.....调试等等操作。
如果使用对象,只需要修改sql语句就行了。这叫不变应万变。
代码更加简洁,规范,容易懂
不好范例
public class UserController{
@RequestMapping("getUserInfo")
public UserInfo getUserInfo(Long userId ){
}
@RequestMapping("newGetUserInfo")
public UserInfo appIdAndUserIdGetUserInfo(Long userId , Long appId){
}
@RequestMapping("newGetUserInfo")
public UserInfo ageAndUserIdGetUserInfo(Long uId , Long age,){
}
}
上面形参userId与uId其实是一个意识,但是因为开发人员忽视或者由不同开发人员开发,每个人的行为习惯不一样。操作形参命名不同,造成维护与沟通成本剧增。
好的范例
一个接口就可以搞定了。由mybatis去识别下参数。
public class UserController{
@RequestMapping("getUserInfo")
public UserInfo getUserInfo(UserInfo userInfo ){
}
}
代码更加简洁,规范,容易懂
不好范例
public class UserController{
@RequestMapping("getUserInfo")
public UserInfo getUserInfo(Long userId ){
}
@RequestMapping("newGetUserInfo")
public UserInfo appIdAndUserIdGetUserInfo(Long userId , Long appId){
}
@RequestMapping("ageAndUserIdGetUserInfo")
public UserInfo ageAndUserIdGetUserInfo(Long userId , Long age, Long appid){
}
}
好的范例
不管加多少个接口或者多少个Controller,只要看到UserInfo对象。调用者基本知道这方法作用和行为。不需要在去理解参数。
public class UserController{
@RequestMapping("getUserInfo")
public UserInfo getUserInfo(UserInfo userInfo ){
}
@RequestMapping("newGetUserInfo")
public UserInfo appIdAndUserIdGetUserInfo(UserInfo userInfo){
}
@RequestMapping("ageAndUserIdGetUserInfo")
public UserInfo ageAndUserIdGetUserInfo(UserInfo userInfo){
}
......
}
public class UserLogController{
@RequestMapping("getUserInfo")
public UserInfo getUserLog(UserInfo userInfo ){
}
......
}
千万不要在实体与其他传输对象之间转化
实体与xxxInput和xxxOnput转换
public class UserController{
@RequestMapping("getUserInfo")
public UserInfo getUserInfo(UserInfoInput userInfoInput ){
UesrInfo userInfo = new UserInfo();
userInfo.setUid(userInfoInput.getUid());
userInfo.setName(userInfoInput.getName());
userInfo.setAge(userInfoInput.getAge());
userInfo.setAppId(userInfoInput.getAppId());
userInfo.setAddree(userInfoInput.getAddree());
// 进行一些业务操作
UesrInfoOuput userInfoOuput = new UesrInfoOuput();
userInfoOuput.setUid(userInfo.getUid());
userInfoOuput.setName(userInfo.getName());
userInfoOuput.setAge(userInfo.getAge());
userInfoOuput.setAppId(userInfo.getAppId());
userInfoOuput.setAddree(userInfo.getAddree());
}
}
- 与他人合作开发一个模块,一个类里面600行代码,其中300多行代码是各种实体与OUput与input的转换,直接看崩了。
- 在一些复杂的业务中,数据对象之间的转换是十分难以理解,阅读的。
- 需要消耗大量的时间,创建input与ouput对象,目录。大大的提高了开发成本,维护成本。
有些会问返回的时候,不想别人知道映射关系。这个问题很简单。
- 字段命名与变量命名不同。
- mybatis映射不同
- json序列化的时候,命名不同就行了。
总结
简单就是美,管理与架构的本质是提高效率,而大量的数据对象转换,从而大大的降低了效率。得不偿失。