最近的评论

• 评论了主题 源码疑惑---求解，这两种写法有什么不同吗？
  在lock和unlock之间, 有return语句, 跳出函数情况时. defer的写法, 会确保unlock的会被执行. 另外一种写法则不会.
• 评论了博文 在 Golang 中尝试简洁架构
  我也有写过类似的项目. 几个问题很纠结: 1) 按领域驱动来说, usecase层代码要真正体现对业务逻辑的表达, 需要通过领域实体对业务进行建模. 那么领域实体, 和仓储层的实体(数据表), 不应该是一个东西. 对于简单业务来说, 领域实体与仓储层的实体 非常类似, 多写一次很麻烦, 对象间赋值也很麻烦. 但是, 对于稍微复杂业务, 共用实体也在实践中导致很多问题, 比如, 实体上不不断的被添加很多扩展的属性(成员). 来表达业务的状态, 或者为了拼凑对象让接口层刚好返回API的需要的数据. 时间一长, 变得混乱. 2) 对于聚合查询, 其实从可以API层, 直接访问仓储层, 跳过usecase层. 3) usecase层, 跟仓储的db对象是解耦的, 那么如何在业务中表达事务? 事务也是业务逻辑的重要组成部分. 我的做法是建立事务的抽象接口. 这是一个重要的问题. 4) api层的独立测试, api层逻辑主要是出入参的校验, 转换, 组装, 写测试用例实际的投入产出比不高. 把api层+usecae层一起测试, 实践中更实用. 所以, 可以不对usecase层做接口定义. 当然, 对多个usecase间有依赖的情况, 没有接口, 难实现usecase的独立测试, 也是个纠结点. 5) 一些动态参数的传递, 比如,列表的查询条件, 其实用map会方便很多. 不论用不用ORM框架, 仓储层都要出现这种逻辑代码, if xx条件有值 then + 'and xx=?' , 最终生成动态的where sql语句. 这种参数个人觉得map比struct方面很多, 当然牺牲参数校验的便利性. 总之, 分层清晰了, 解耦了, 代码就啰嗦了, 写起来就狗屎了. 加个参数, 代码改一大圈.
• 评论了博文 golang 关于bool一个奇怪的问题
  goos: linux goarch: amd64 pkg: demo2 BenchmarkBSTrue-8 1000000000 0.349 ns/op 0 B/op 0 allocs/op BenchmarkBSFalse-8 1000000000 0.333 ns/op 0 B/op 0 allocs/op PASS ok demo2 0.772s unbuntu, go1.14.6 跟你的结果不一样，是false快一些。