这是一个创建于 964 天前的主题，其中的信息可能已经有所发展或是发生改变。
这是用 Go 写微服务系列第二篇, 围绕于业务层中的标准方法展开.
主要内容如下:
- 如何实现 Google API 设计指南中的五个标准方法
- 如何处理声明式参数绑定和校验
- 如何简化和复用处理 SQL 事务的代码
由于里面处理事务的方式是我自己想的, 所以如果有更直观的方案 (尽量不加额外的依赖) 欢迎留言讨论.
照例贴下第一段引言.
引言
在 前篇文章 中我们搞定了最基础的三件事: 启动, 路由, 可观测性. 正因为基础, 所以这部分代码的变化频率也是最低的.
这次我们就集中精力来处理变化稍快的业务层. 按照我们之前的规则, 业务层其实也可以分成两部分: API 和 具体实现. 其中 API 较为稳定, 很少出现破环性的变更, 一般维护良好的 API 会充分考虑其兼容性. 相较而言, 具体实现的变化速度就快得多了.
由于这篇文章的主要目的还是带着大家一起写代码, 所以如何得到一个设计良好的 API 就不是本篇的重点了, 想深入了解的话推荐读读看 <软件设计哲学> 这本书. 这里我就直接采用 Google API 设计指南 中的接口方案了, 可以稍微浏览下, 有个大概的概念.
至于业务场景, 就假想一个购物车的场景吧, 之后正好可以用来说明事务处理相关的流程. 数据库选择 SQLite, 这样方便在本地把 Demo 跑起来.
另外, 这次我考虑把篇幅稍微控制一下, 上次一口气写太多了, 估计读起来也挺累的 XD.
 |
1
lanlanye 2022-04-29 03:50:19 +08:00
前篇地址 404 ，不过通过 blog 找到了，支持干货。
说到 Google API Design ，Golang 主流的 router 在处理 URL 参数时都选择了冒号前缀，很难受;( |
Select Language