如何根据Clean Architecture在Golang中实现演示者?
适当的软件架构是创建可维护项目的关键.什么适当的手段是100%主观的,
但最近我喜欢并尝试遵循Robert C. Martin(又名叔叔鲍勃)的 Clean Architecture. 虽然我非常喜欢这个理论,但它缺乏开发人员可能面临的常见技术挑战的实用实施指南. 演示者负责接受我的用例中的“响应”并以某种方式对其进行格式化 这个问题有多种方法,但它们通常属于以下类别之一: >用户通过某种输出接口调用演示者 选项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(用例调用演示者),我必须以某种方式将它传递给演示者,这种方式变为请求作用域,而应用程序的其余部分完全无状态且不请求作用域,它们被实例化一次. 这也意味着我要么将响应编写器本身传递给用例和演示者(我宁愿不这样做),也不要为每个请求创建一个新的演示者. 我在哪里可以做到: >在控制器中通过工厂 这带来了另一个问题:如果演示者是请求作用域,那么用例也是如此吗? 如果我想将演示者注入用例结构,那么它是,并且必须在控制器中创建用例. 或者,我可以使演示者成为用例的参数(没有人说必须在“构建时”注入依赖项).但这仍然会将演示者与控制器联系起来. 还有其他未解决的问题(比如我应该在哪里发送HTTP标头),但这些不是特定于Go的. 这是一个理论问题,因为我还不确定我是否想要使用这种模式,但到目前为止,我已经花了很多时间思考这个问题而没有找到完美的问题. 根据articles and questions我读过这个话题:其他人也没有. 解决方法
我可以根据Clean Architecture告诉你我的经历.我花时间研究这个问题,阅读文章和测试代码.所以我想建议你以下帖子和附带的源代码,它对我帮助很大:
> Applying The Clean Architecture to Go applications 这是一个非常好的起点,我正在以这种方式设计我的软件,开发宁静的Web应用程序,直到演示给通过jQuery和Bootstrap的用户.我可以声称,现在我的软件真的被转移到了独立的层.它还帮助我找到了te golang接口的强大功能,最终对软件的每个部分进行了简单的测试.希望这也对你有所帮助. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |