业务代码的管理

避免业务代码量带来的臃肿问题

项目工程随着时间以及业务需求的扩展,随之带来的问题问题是业务量越来越多,例如常见的html页面可能动辄两三千多行,service类少则一千多行,代码阅读难以理解,维护工作量大,是什么原因造成的?一个良好代码编写习惯真的能避免这种问题。

实际过程中的案例

请假销假相关的业务,二者既有关联的地方,也有独立的地方,相关的方法完成可能抽离处理。实际过程一般分为两部分:

请假业务类:

@Service
public class LeaveServiceImpl extends BaseService<Myleave> implements LeaveService {
	
}

销假业务类:

@Service
public class SalesleaveServiceImpl extends BaseService<Salesleave> implements SalesleaveService {
	
}

随着业务需求的增多,这两个类不加以控制,代码量都会充斥在其中,例如这种代码:

private String getShopname(Long deptId) {
        StringBuffer sb = new StringBuffer();
        XgjDeptDto xgjDeptDto = xgjDeptMapper.findDeptInfoByDeptId(deptId);
        if(xgjDeptDto!=null){
            if(StringUtils.isNotBlank(xgjDeptDto.getCompanyName())){
                sb.append(xgjDeptDto.getCompanyName()).append("-");
            }
            if(StringUtils.isNotBlank(xgjDeptDto.getAreaName())){
                sb.append(xgjDeptDto.getAreaName()).append("-");
            }
            if(StringUtils.isNotBlank(xgjDeptDto.getShopName())){
                sb.append(xgjDeptDto.getShopName()).append("-");
            }
            return sb.substring(0,sb.length()-1);
        }
        return null;
}

根据部门id或者名称全缀,只能是给当前类进行使用。这种代码增多会导致业务量臃肿!

解决思路

将臃肿的service进行拆分,拆分为更细的series类。比如service中F需要调用A,B,C三件事才能完成,将ABC非核心service的抽离出来放置到ServiceHandle类中进行处理!

例如销假类的业务请求,新增handle类:

public class SalesleaveServiceHandle {
    private static SalesleaveServiceHandle instance;

    private SalesleaveServiceHandle() {}

    public static SalesleaveServiceHandle getInstance() {
        if(instance == null) {
            instance = new SalesleaveServiceHandle();
        }
        return instance;
    }

    /**
     * 获取小店名称
     * @param xgjDeptMapper
     * @param deptId
     * @return
     */
    protected String getShopname(XgjDeptMapper xgjDeptMapper,Long deptId) {
        StringBuffer sb = new StringBuffer();
        XgjDeptDto xgjDeptDto = xgjDeptMapper.findDeptInfoByDeptId(deptId);
        if(xgjDeptDto!=null){
            if(StringUtils.isNotBlank(xgjDeptDto.getCompanyName())){
                sb.append(xgjDeptDto.getCompanyName()).append("-");
            }
            if(StringUtils.isNotBlank(xgjDeptDto.getAreaName())){
                sb.append(xgjDeptDto.getAreaName()).append("-");
            }
            if(StringUtils.isNotBlank(xgjDeptDto.getShopName())){
                sb.append(xgjDeptDto.getShopName()).append("-");
            }
            return sb.substring(0,sb.length()-1);
        }
        return null;
    }
}

更甚至,若是业务方法通用,很多类使用到则需进一步提取公用方法,名字起好!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值