Question

我无法理解在golang中组织应用程序依赖结构的最佳方法。

本质上，我的应用程序的结构如下：

accounts
  ...
  handlers
    accounts.go
  models
    account.go
  repos
    account.go

现在我有一个用于帐户的数据库访问对象（DAO）设置，我想避免在其中放置验证逻辑，因为这更适合模型域。回购旨在仅处理与数据库的交互。

在模型内部，我认为进行验证是有意义的。但是，一种验证（例如电子邮件的唯一性）要求使用DAO，该DAO会引发有关循环调度的错误。

我很好奇在这种范例中组织验证的最佳方法是什么？我是否真的应该包括一个用于所有交互的服务层？也就是说，我是否应该拥有一个仅作为Account结构的模型，然后进行验证并在将钩子保存到服务中之前？

Answer 1

采用三层体系结构可以帮助缓解您遇到的一些问题。

您遇到问题的原因是，没有一个地方拥有模型验证。没有一个地方可以提取执行该验证所需的所有信息。

（几乎总是）验证基于一组业务规则（或逻辑规则）。这些规则与数据的结构（由模型包拥有）或数据存储（由dao层拥有）无关。

在所有代码层中添加一个服务层，以使用模型和存储库包，这将为您提供一个封装验证模型所需的逻辑规则的地方。还将为您提供一个逻辑位置进行验证。

通常，我主张总是添加服务层。即使它什么也没做。此经验法则提供了一种更灵活的设计，允许更改需求。

Answer 2

我曾经做过的一件事，尽管我认为它有点骇人听闻，但却是使用接口或函数指针。在您的情况下，它将在您的模型中。

然后在应用程序中更高级的代码中，可以使用模型和DAO而不使用循环引用，由该代码设置接口或函数指针。

模型可以调用该方法而无需其代码。

我想这是依赖注入的一种形式。我自己做时并不满意，但是那是当时最简单的方法。