感想3-对于业务逻辑复用、模板复用的一些思考(未完)

内容概览：

• 业务逻辑复用的目的
• 基于现有场景，如何抽象出初步可复用逻辑
• 复用业务逻辑会不会产生过分设计的问题

 

业务逻辑复用的目的

　　我对于业务逻辑复用的理解是忽略实际业务内容，从交互流程、交互逻辑的角度去概括、总结，提出通用的标准流程或者经常使用函数，而后再mixins(混入)到业务逻辑中。Mixins有点相似AOP—面向切面编程。所谓的mixins就是将组件里的方法抽出来。实际上Mixins里的this是指向组件的，使用了Mixins之后，组件也能够调用Mixins里的方法。

　　好处是共用一些功能，共享一部分代码，这样作咱们就处处写重复的代码，下降类型、功能类似业务的开发、维护成本。

 

基于现有场景，如何抽象出初步可复用逻辑

　　带查询的列表展现页就是一种常见的可抽象出复用功能的业务场景。好比咱们能够将这种场景概括为搜索 => 更新列表。

　　搜索自己会有多种出触发方式，搜索条件触发、分页触发、自动更新。除了自动更新，剩下两种方式本质上都是请求参数改变。只要咱们作好对参数收集的封装，其他部分都是同样的。以下为各部分大体包含方法：

• 业务模块：params_collection(参数收集) 、service_get_list_data(获取列表数据的异步请求，用fetch或promise封装)
• 搜索条件触发mixins:  update_list(更新列表，负责调用service_get_list_data，更新列表数据)、do_query(查询动做，负责调用params_collection、update_list)
• 分页触发mixins: pagination_change(分页信息更新，负责更新分页信息，而后调用do_query)
• 自动更新更多的是须要关注定时器的问题，不在本文讨论范围。

　　未完待续...

复用业务逻辑会不会产生过分设计的问题

　　未完待续...