teambition-sdk
teambition-sdk copied to clipboard
Meeting Notes 2016.11.9
主要存在的问题:
- API 里面 get 的方法语义不明确
- Model 中涉及到的业务逻辑太多,没办法抽象
- 由第二个问题引发的一个后端 API 对应不同的
query
导致业务上需要拆分成 N 个 SDK 的 API:
getMyDueTasks(_userId: UserId, query?: any): Observable<TaskData[]>
getMyTasks(_userId: UserId, query?: any): Observable<TaskData[]>
结论
- 所有 API 的
get
方法拆分,比如getMyTasks
拆分成listenMyTasks
+getMyTasks
:
这样在开发业务的时候需要区分 listen
语义的调用和 CRUD
语义的调用。 listen 的调用只关注数据,CRUD 的调用只关注状态。
-
Model 中涉及到的业务逻辑全部让调用方从外部传进来(其实目前只涉及到 Collection select Condition), 然后 SDK 在内部根据 query + select condition 创建不同的 Collection。
-
由于业务部分的逻辑从 SDK 剥离,那么第三个问题很好解决,一个 API 对应一个后端 API,动态的 query 和 select condition 由外部传入动态生成。
悬而未决的问题
- Collection 分页的行为还需要进一步确认,最好是在实际的业务场景中确认这个 Pattern 是清晰可行的。
- Collection 的底层实现 (Subject/Observable) 需要验证。
下一阶段的目标
-
决定分离
get
API 的具体实现细节: 将get()
变成listen() + get()
或get().run() + get().listen()
。 由 @xufei @aicest @Brooooooklyn 讨论后决定 -
抽离
Model
层的业务逻辑: @Brooooooklyn 实现,包括重构测试的任务,预计一个 sprint 内完成。 -
抽象 query + condition + fetch => API 的过程,最好是做到新加一个 API ,SDK 仅在 API 层加几行代码就能实现。 @Brooooooklyn @xufei 讨论后实施。
下一个 sprint 将继续跟进这三个问题 😈