Go 数据操作之 grop 和 sqlx
一直使用 grop ，当时觉得它够轻量，但又不是纯粹的 ORM ，所以造就它拥有非常简便和较高性能的特征，实际使用中，印证了它这两个优点。使用它的时候，有使用 Java 界 Jfinal ORM 的感觉，非常接近，我不知道 他们两者是否参照了同一个前辈产品。当然 Java 和 Go 特征上有很大的差别，比如 泛型 等等，Go 是没有泛型的，造成了个别差异，不过 API 算吻合。
2015年后，gorp 慢慢发展，已经不像当初那么轻量了，特别正在开发的 2.0 版本，文件数量比之前翻了番，粗略看了下，功能越来越完善了。
后来我碰见了 大猩猩成员的 sqlx 类，按照以往的经验比较，发现 sqlx 偏向于原生态，遵循了 Go 的推崇的方式，我不知道作者是不是想往 Go 内置方向努力，他介绍说，sqlx 只是对 Go 的 database/sql 一个扩展，使用上当然比 database/sql 用得更便捷，更强大，像 Java 界的 Dbutils 一样的地位，不过有些不一样，sqlx 支持事务。
最新尝试了下 sqlx，发现确实够原生，用起来需要写不少的代码，可能习惯了 grop 的缘故。代码量多了，可能还不太熟悉，灵活性无法体验出来。开发项目中，分别都使用了两者，最后还是回到 gorp，因为发现 sqlx 就是一个加强版的 database/sql，后台开发的时候，不禁怀念起 gorp...
2015年后，gorp 慢慢发展，已经不像当初那么轻量了，特别正在开发的 2.0 版本，文件数量比之前翻了番，粗略看了下，功能越来越完善了。
后来我碰见了 大猩猩成员的 sqlx 类，按照以往的经验比较，发现 sqlx 偏向于原生态，遵循了 Go 的推崇的方式，我不知道作者是不是想往 Go 内置方向努力，他介绍说，sqlx 只是对 Go 的 database/sql 一个扩展，使用上当然比 database/sql 用得更便捷，更强大，像 Java 界的 Dbutils 一样的地位，不过有些不一样，sqlx 支持事务。
最新尝试了下 sqlx，发现确实够原生，用起来需要写不少的代码，可能习惯了 grop 的缘故。代码量多了，可能还不太熟悉，灵活性无法体验出来。开发项目中，分别都使用了两者，最后还是回到 gorp，因为发现 sqlx 就是一个加强版的 database/sql，后台开发的时候，不禁怀念起 gorp...
哇~~~ 竟然还没有评论！