对于REST API，您通常需要处理至少三个不同的实现层：
- HTTP处理程序
- 某种业务逻辑/用例
- 持久存储/数据库接口
您可以将每个部分单独处理和构建，这不仅解耦了它们，而且使其更易于测试。然后通过注入所需的位来将这些部分组合在一起，因为它们符合您定义的接口。通常，这最终会将main或单独的配置机制留给唯一知道已组合和注入了什么和如何的地方。
应用清洁架构到Go应用程序这篇文章非常好地说明了如何分离各个部分。您应该严格遵循这种方法的程度取决于项目的复杂性。
以下是一个非常基本的分解，将处理程序与逻辑和数据库层分开。
HTTP处理程序
处理程序除了将请求值映射到本地变量或可能需要的自定义数据结构之外，什么也不做。除此之外，它只运行用例逻辑并在将结果写入响应之前映射结果。这也是将不同错误映射到不同响应对象的好地方。
type Interactor interface {
Bar(foo string) ([]usecases.Bar, error)
}
type MyHandler struct {
Interactor Interactor
}
func (handler MyHandler) Bar(w http.ResponseWriter, r *http.Request) {
foo := r.FormValue("foo")
res, _ := handler.Interactor.Bar(foo)
json.NewEncoder(w).Encode(res)
}
单元测试是一种很好的测试方式，可以测试HTTP响应是否包含了不同结果和错误的正确数据。
使用案例/业务逻辑
由于仓库只是指定为一个接口，因此可以非常容易地创建针对业务逻辑的单元测试，通过使用符合 DataRepository 接口的模拟仓库实现返回不同的结果。
type DataRepository interface {
Find(f string) (Bar, error)
}
type Bar struct {
Identifier string
FooBar int
}
type Interactor struct {
DataRepository DataRepository
}
func (interactor *Interactor) Bar(f string) (Bar, error) {
b := interactor.DataRepository.Find(f)
return b
}
数据库接口
与数据库对话的部分实现了DataRepository接口，但在将数据转换为预期类型方面完全独立。
type Repo {
db sql.DB
}
func NewDatabaseRepo(db sql.DB) *Repo {
return &Repo{db: db}
}
func (r Repo)Find(f string) (usecases.Bar, error) {
rows, err := db.Query("SELECT id, foo_bar FROM bar WHERE foo=?", f)
if err != nil {
log.Fatal(err)
}
defer rows.Close()
for rows.Next() {
var id string, fooBar int
if err := rows.Scan(&id, &fooBar); err != nil {
log.Fatal(err)
}
return usecases.Bar{Identifier: id, FooBar: fooBar}
}
return errors.New("not found")
}
再次强调，这使得可以在不需要任何模拟SQL语句的情况下单独测试数据库操作。
注意：上面的代码非常类似伪代码且不完整。
