book/advanced-go-programming-book
1
0
Fork 0
mirror of https://github.com/chai2010/advanced-go-programming-book.git synced 2025-05-23 20:02:22 +00:00
Code Issues Releases Wiki Activity

Merge pull request #433 from fuwensun/master

Browse Source 
ch5-5 fix typo
This commit is contained in:
Xargin 2019-07-11 01:13:25 +08:00 committed by GitHub
commit 8d23f5bbf5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ch5-web/ch5-05-database.md
View File

@ -155,9 +155,9 @@ num, err := o.QueryTable("cardgroup").Filter("Cards__Card__Name", cardName).All(
你可以看得出来这个Filter是有表join的操作么？当然了，有深入使用经验的用户还是会觉得这是在吹毛求疵。但这样的分析想证明的是，ORM想从设计上隐去太多的细节。而方便的代价是其背后的运行完全失控。这样的项目在经过几任维护人员之后，将变得面目全非，难以维护。
当然，我们不能否认ORM的进步意义，它的设计初衷就是为了让数据的操作和存储的具体实现所剥离。但是在上了规模的公司的人们渐渐达成了一个共识，由于隐藏重要的细节，ORM可能是失败的设计。其所隐藏的重要细节对于上了规模的系统开发来说至关重要。
当然，我们不能否认ORM的进步意义，它的设计初衷就是为了让数据的操作和存储的具体实现相剥离。但是在上了规模的公司的人们渐渐达成了一个共识，由于隐藏重要的细节，ORM可能是失败的设计。其所隐藏的重要细节对于上了规模的系统开发来说至关重要。
相比ORM来说，SQL Builder在SQL和项目可维护性之间取得了比较好的平衡。首先sql builer不像ORM那样屏蔽了过多的细节，其次从开发的角度来讲，SQL Builder简单进行封装后也可以非常高效地完成开发，举个例子：
相比ORM来说，SQL Builder在SQL和项目可维护性之间取得了比较好的平衡。首先sql builder不像ORM那样屏蔽了过多的细节，其次从开发的角度来讲，SQL Builder进行简单封装后也可以非常高效地完成开发，举个例子：
```go
where := map[string]interface{} {
@ -195,7 +195,7 @@ if order_id != 0 {
res, err := historyModel.GetList(where, limit, orderBy)
```
你的系统里有类似上述样例的大量`if`的话，就难以通过测试用例来覆盖到所有可能的sql组合了。
你的系统里有大量类似上述样例的`if`的话，就难以通过测试用例来覆盖到所有可能的sql组合了。
这样的系统只要发布，就已经孕育了初期的巨大风险。