如何解决这个周期性依赖

Question

我一直在学习Go for class课程，我对这门语言感到非常兴奋，它对网络服务非常有用。

所以，我一直在为最终项目编写这个CRUD restful API，并且我一直在运行该死的循环依赖问题。我已经研究并阅读了解决它的方法，并且会在这里发布，但首先是我遇到的问题：

routes 需要了解处理程序包中的处理程序函数，而这些函数又需要了解 user 结构中的 user 结构。 em> model 包，为了发送带有链接的注册电子邮件，需要了解路由路径

古典A - ＆gt; B - ＆gt; C - ＆gt;甲

现在，我正在尝试使用MVC和三层架构编写此API，我希望我的路由位于控制器包中，我的处理程序位于业务逻辑包上，而我的用户位于模型包上。这也是需要的，因为我有超过43个模型类，我需要它们整理并隐藏在它们的包装上。

好的，我发现的解决方案

1 - 将所有人扔在同一个包裹上：这是我迄今为止所做的事情，但由于显而易见的原因，这是一个非常可怕的解决方案。

2- 传递用户需要的任何东西作为参数时调用它的功能：这将是一个很好的解决方案，但不会起作用，因为从用户调用的函数来自一个接口实现，因为它必须是一个通用的调用，并且在任何人到处说我的问题是因为我强行执行泛型，太糟糕了，我需要那个泛型，我不会写超过160个crud函数。功能的全部意义在于避免代码重复。

3- 使用另一个界面创建另一个包，并让它具有处理程序和用户的实例，并让它从一个参数传递给另一个：尽管上面提到的原因，需要通用，这听起来像一个不必要的复杂解决方案，我拒绝相信这是比循环依赖更好的设计。

底线问题：当C需要知道来自A和泛型的信息时，如何解决这种依赖性

如果您需要，我可以在这里发布一些代码，但如果这不是一个高级别的问题，我就不会看到特定代码的相关性。

编辑：解决了我的依赖问题。谢谢大家的评论和回答，因为它引导我得到答案。我不认为我已经实施了任何建议的解决方案，但它确实教会了我很多关于如何解决问题的方法，如果不是这样的话，它们都是非常可接受和可行的解决方案。我自己的约束，我不想把任何东西传递给用户。 对于任何试图解决他们自己的依赖问题的人来说，我能够收集的是，而不是在我的情况下，C向A提出一些问题，在它需要之前给予C任何需要的东西，意思是将信息传递给他

唉，这不是我的解决方案，我所做的是从A中删除信息并将信息提供给Z，现在A和C都要求路径信息到Z，这只是一张地图，坐在那里映射和保存信息。 谢谢大家

Answer 1

你有一些选择，而且你已经找到了一些选择。处理这个问题的主要方法是：

• 重构您的设计，将循环变成树。由于您的要求，这并不适用于您的情况。
• 重构您的设计以使用某种依赖注入（这是您问题中的第二个选项）。这是完全可行的，可能是最干净，最简单的。
• 重构您的设计以采用本地声明的界面。这是您的选项3的更加Go-idiomatic版本。因为Go中的接口是鸭子类型，所以您可以将其定义在消耗的位置，而不是它的实现位置。所以你的用户包可以为“一个给我一个我需要的URL的东西”定义一个单方法接口，它永远不需要引用实现该接口的包。