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

适当的软件架构是创建可维护项目的关键.什么适当的手段是100％主观的,
但最近我喜欢并尝试遵循Robert C. MarTin(又名叔叔鲍勃)的 Clean Architecture.

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

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

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

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

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

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

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

另外,请原谅我的简洁.

@H_404_31@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(用例调用演示者),我必须以某种方式将它传递给演示者,这种方式变为请求作用域,而应用程序的其余部分完全无状态且不请求作用域,它们被实例化一次.

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

我在哪里可以做到：

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

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

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

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

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

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

根据articles and questions我读过这个话题：其他人也没有.