代码重构 - 后端部分代码

前一篇主要写了一下前端部分的重构,这一篇则主要关注后端部分。

在前一篇后面说到了一个很实用的套路(模式),其类图如下图所示:


UML类图

在后端部分,我先将后端Java代码的类图画出来:


UML类图

可以发现,还是一样的套路。

代码实现

下面则具体说下实现,首先是说一下原来的系统的实现,然后是重构的实现。

原来的实现

在上一篇前端部分,拿了两个方法作为示例,在方法体的后面,则都是通过POST请求调用后端的Controller。

postVue("${ctx}/BusinessOpportunity/openAcct",params,function (data) {......
postVue("${ctx}/BusinessOpportunity/openAmlInviteAcct",params,function (data) {......

这里是原有的Controller的实现:

Controller

Controller

然后则是Service的实现:

Service

Service

然后就是Service调用不同的MyBatisdao层实现。

调用过程

从实现上来说,就是一一相对应,优点是代码过程清晰明了,基本上完全反映实现的意图。缺点自然也很明显,比如大量重复的代码,并且也没有代码复用等。

重构过程

这部分这样描述下重构的部分。上一篇中提到了我对于重构的两个原则:

  1. 尽可能的代码复用
  2. 为使用方提供一致的调用外观

所以这一部分,还是会基于这两个主要原则,并且主要针对Controller层和Service层。

由于是前后端分离,所以这部分是Restful风格的,WEB API作为前后端的契约,一是URL尽量的符合REST语义,二是传输的数据(payload)。

这个是REST Controller的实现:

@PostMapping("/api/opportunities/batch")
public ResponseEntity<?> batchProcess(@RequestBody OpportunityBatchRequest request) {
    log.info("Process opportunity batch action - type: {}", request.getType());
    List<String> emailSendFailedList;
    try {
        businessOpportunityProcessorService.process(request);
        emailSendFailedList = businessOpportunityProcessorService.getAllEmailSendFailed();
    } catch (Exception e) {
        log.error("Process opportunity batch action failed, type: {}, root cause: {}", request.getType(), e);
        return WebUtil.error(e.getMessage());
    }

    String message = "保存成功,以下企业发送通知失败,请检查:" + String.join(", ", emailSendFailedList);

    return new ResponseEntity<>(RestResponse.builder().status(HttpStatus.OK.value()).body(Boolean.TRUE).message(message).build(), HttpStatus.OK);
}

`/api/opportunities` 这部分其实是放`RestController`类注解上的,这里只是为了说明。
另外,按照REST语义,针对不同的资源的操作,是区分GET、POST、DELETE等动词的,但是在真实的项目环境下,其实很难严格按照REST语义的,所以这里针对批处理的方式,统一使用了POST。

这个是RequestBody的部分,作为数据(schema),type表述执行什么操作,data则是本次操作的数据部分。

@Data
@ToString
public class OpportunityBatchRequest {
    private String type;
    private List<RequestData> data;

    @Data
    public static class RequestData {
        private String companyName;
        private String contactNumber;
        private Integer customerId;
        private String email;
        private String opportunityId;
    }
}

这部分就是针对批处理操作的Controller层,下面则是Service层,由于在上面已经给出了UML类图,所以这里主要是给出一些具体的实现:

首先是定义接口,用以规范行为,这边的泛型其实并没有实际的意义,直接就是OpportunityBatchRequest这个类

public interface OpportunityProcessor<T> {
    boolean supports(String type);
    void process(T request) throws ProcessException;
}

主要是两个方法:

  • supports:用以在具体的实现类中表达支持哪种type的处理
  • process: 业务处理方法

具体的子类的实现示例如下:

/**
 * 开通反洗钱
 */
@Service
@Slf4j
public class OpenAmlAccountProcessor extends AbstractOpportunityProcessor<OpportunityBatchRequest> {
    private static final String SUPPORTS_TYPE = "OpenAmlAccount";

    @Override
    public boolean supports(String type) {
        return SUPPORTS_TYPE.equalsIgnoreCase(type);
    }

    @Override
    public void process(OpportunityBatchRequest request) throws ProcessException {
        log.info("Process OpenAmlAccount action");

    }
}
/**
 * 开通反洗钱邀请
 */
@Service
@Slf4j
public class OpenAmlInviteAccountProcessor extends AbstractOpportunityProcessor<OpportunityBatchRequest> {
    private static final String SUPPORTS_TYPE = "OpenAmlInviteAccount";

    @Override
    public boolean supports(String type) {
        return SUPPORTS_TYPE.equalsIgnoreCase(type);
    }

    @Override
    public void process(OpportunityBatchRequest request) throws ProcessException {
        log.info("Process OpenAmlInviteAccount action");

    }
}

这里的抽象父类AbstractOpportunityProcessor,用以处理一些较为公共的逻辑等,比如注入公共组件,抽些公共的方法等。引入这个抽象类的性价比是很高的。

重构后的代码

这个例子中,有几个操作都是开通账号、邀请相关的,所以,涉及开通账号方法,就可以放在这个抽象父类中,而相应的子类,则只需要说明账户类型,就可以了:

/**
 * 开通反洗钱
 */
@Service
@Slf4j
public class OpenAmlAccountProcessor extends AbstractOpportunityProcessor<OpportunityBatchRequest> {
    private static final String SUPPORTS_TYPE = "OpenAmlAccount";
    private static final String ACCOUNT_OPEN_MODE = Constants.AcctOpenMode.AML;

    @Override
    public boolean supports(String type) {
        return SUPPORTS_TYPE.equalsIgnoreCase(type);
    }

    @Override
    public void process(OpportunityBatchRequest request) throws ProcessException {
        log.info("Process OpenAmlAccount action");

        for (OpportunityBatchRequest.RequestData requestData : request.getData()) {
            openAccount(requestData, ACCOUNT_OPEN_MODE);
        }
    }
}

/**
 * 开通反洗钱邀请
 */
@Service
@Slf4j
public class OpenAmlInviteAccountProcessor extends AbstractOpportunityProcessor<OpportunityBatchRequest> {
    private static final String SUPPORTS_TYPE = "OpenAmlInviteAccount";
    private static final String ACCOUNT_OPEN_MODE = Constants.AcctOpenMode.INVITE_AML;

    @Override
    public boolean supports(String type) {
        return SUPPORTS_TYPE.equalsIgnoreCase(type);
    }

    @Override
    public void process(OpportunityBatchRequest request) throws ProcessException {
        log.info("Process OpenAmlInviteAccount action");

        for (OpportunityBatchRequest.RequestData requestData : request.getData()) {
            openAccount(requestData, ACCOUNT_OPEN_MODE);
        }
    }
}
AbstractOpportunityProcessor#openAccount

而对于其他的操作,则只需要在具体自己的子类中实现,如删除:

/**
 * 批量删除
 */
@Service
@Slf4j
public class DeleteOpportunitiesProcessor extends AbstractOpportunityProcessor<OpportunityBatchRequest> {
    private static final String SUPPORTS_TYPE = "DeleteOpportunities";

    @Override
    public boolean supports(String type) {
        return SUPPORTS_TYPE.equalsIgnoreCase(type);
    }

    @Override
    public void process(OpportunityBatchRequest request) throws ProcessException {
        log.info("Process DeleteOpportunities action");

        List<String> opportunityIdList = request.getData()
                .stream()
                .map(OpportunityBatchRequest.RequestData::getOpportunityId)
                .collect(Collectors.toList());
        businessOpportunityMapper.deleteOpportunitiesInBatch(opportunityIdList);
    }
}

后记

这是本次重构的后端部分,相应的套路(模式)也更多一些,自己也相对的更加熟悉一些。这两篇博客提到的模式,在很多场景下都可以使用。

谢谢阅读。

Works,then better.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,602评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,442评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,878评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,306评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,330评论 5 373
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,071评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,382评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,006评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,512评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,965评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,094评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,732评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,283评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,286评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,512评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,536评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,828评论 2 345

推荐阅读更多精彩内容

  • Swift1> Swift和OC的区别1.1> Swift没有地址/指针的概念1.2> 泛型1.3> 类型严谨 对...
    cosWriter阅读 11,089评论 1 32
  • iOS网络架构讨论梳理整理中。。。 其实如果没有APIManager这一层是没法使用delegate的,毕竟多个单...
    yhtang阅读 5,165评论 1 23
  • 发现 关注 消息 iOS 第三方库、插件、知名博客总结 作者大灰狼的小绵羊哥哥关注 2017.06.26 09:4...
    肇东周阅读 12,029评论 4 62
  • 近日,河北省作家协会会员、河北省文学院签约作家张梅英散文集《梅好时光》由四川美术出版社出版发行。 据了解,《梅好时...
    d3c28a312600阅读 440评论 0 0
  • 人活一世,如露水一朝, 做一个如水的人, 有水的清澈,水的胸怀,水的宁静, 无视纷争,不畏流言,不惧猜疑, 才能过...
    伊秾婕阅读 176评论 0 1