如何根据Clean Architecture在Golang中实现演示者？

Question

适当的软件架构是创建可维护项目的关键.什么正确的方法是100%主观,但最近我喜欢并尝试遵循罗伯特C.马丁(又名叔叔鲍勃)的清洁建筑.

虽然我非常喜欢这个理论,但它缺乏开发人员可能面临的常见技术挑战的实用实施指南.例如,我一直在努力解决的问题之一就是正确实现了presenter层.

演示者负责接受我的用例中的"响应",并以可以"呈现"到我的输出设备的方式对其进行格式化(无论它是Web应用程序还是CLI应用程序).

这个问题有多种方法,但它们通常属于以下类别之一:

1. 演示者由用例本身通过某种输出接口调用
2. 用例返回响应模型,控制器(最初称为用例)将此模型传递给演示者

选项1与Clean Architecture/Uncle Bob所说的大致相同(在书中和各种帖子中,见后文),选项2是另一种有效的方法.

听起来很酷,但让我们看看我们如何在Go中实现它们.

这是我的第一个版本.为简单起见,我们的输出现在转到网上.

另外,请原谅我的简洁.

package my_domain

import "http"

type useCase struct {
    presenter presenter
}

func (uc *useCase) doSomething(arg string) {
    uc.presenter("success")
}

type presenter interface {
    present(respone interface{})
}

type controller struct {
    useCase useCase
}

func (c *controller) Action(rw http.ResponseWriter, req *http.Request) {
    c.useCase("argument")
}

基本上它完全如上所述并且在Clean Architecture中:有一个控制器调用一个用例(通过边界,这里不存在).用例做了一些事情并调用了演示者(没有实现,但这正是问题).

我们的下一步可能是实现演示者....但是考虑到输出如何在Go HTTP处理程序中工作,有一个很好的问题需要解决.即:请求范围.

每个请求都有自己的响应编写器(传递给http处理程序),其中应该写入响应.演示者无法访问全局请求范围,它需要响应编写器.因此,如果我想要遵循选项1(用例调用演示者),我必须以某种方式将它传递给演示者,这种方式变为请求作用域,而应用程序的其余部分完全无状态且不请求作用域,它们被实例化一次.

这也意味着我要么将响应编写器本身传递给用例和演示者(我宁愿不这样做),也不要为每个请求创建一个新的演示者.

我在哪里可以做到:

1. 在控制器通过工厂
2. 在通过工厂的用例中(但话又说明:用例必须接收响应编写器作为参数)

这带来了另一个问题:如果演示者是请求作用域,那么用例也是如此吗？

如果我想将演示者注入用例结构,那么它是,并且必须在控制器中创建用例.

或者,我可以使演示者成为用例的参数(没有人说必须在"构建时"注入依赖项).但这仍然会将演示者与控制器联系起来.

还有其他未解决的问题(比如我应该在哪里发送HTTP标头),但这些不是特定于Go的.

这是一个理论问题,因为我还不确定我是否想要使用这种模式,但到目前为止,我已经花了很多时间思考这个问题而没有找到完美的问题.

基于我读过的有关该主题的文章和问题:其他人也没有.

Answer 1

我可以根据《清洁架构》告诉你我的经历。我在这个问题上花了很多时间，阅读文章并测试代码。所以我想向您推荐以下帖子和所附的源代码，它对我帮助很大：

• 将清洁架构应用于 Go 应用程序

这是一个非常好的起点，我正在以这种方式设计我的软件，开发宁静的 Web 应用程序，直到通过 jQuery 和 Bootstrap 向用户展示。我可以说现在我的软件确实分为独立的层。它还帮助我了解了 te golang 接口的强大功能，并最终对软件的每个部分进行了简单的测试。希望这也对您有帮助。