对于REST API,您通常会处理至少三个不同的实现层:
- HTTP处理程序
- 某种业务逻辑/用例
- 持久存储/数据库接口
您可以分别处理和构建它们中的每一个,这样不仅可以将其解耦,而且还可以使其更易于测试.然后通过注入必要的位将这些部分组合在一起,因为它们符合您定义的接口.通常,这最终会留下main
或单独的配置机制,唯一知道what的地方是组合和注入how.
第Applying The Clean Architecture to Go applications条很好地说明了如何将各个部分分开.您应该严格遵循这种方法的程度在一定程度上取决于项目的复杂性.
下面是一个非常基本的细分,将处理程序与逻辑层和数据库层分开.
HTTP处理程序
处理程序除了根据需要将请求值映射到局部变量或可能的自定义数据 struct 之外,什么也不做.除此之外,它只运行用例逻辑,并在将结果写入响应之前将其映射.这也是将不同的错误映射到不同的响应对象的好地方.
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)
// you may want to map/cast res to a different type that is encoded
// according to your spec
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)
// ... custom logic
return b
}
数据库接口
与数据库对话的部分实现了DataRepository
接口,但在其他方面完全独立于它如何将数据转换为预期的类型.
type Repo {
db sql.DB
}
func NewDatabaseRepo(db sql.DB) *Repo {
// config if necessary...
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)
}
// map row value to desired structure
return usecases.Bar{Identifier: id, FooBar: fooBar}
}
return errors.New("not found")
}
同样,这允许单独测试数据库操作,而无需任何模拟SQL语句.
上面的代码是非常多的伪代码,而且是不完整的.