Go Web App 中是否有必要有 DAL 和 BLL？

Question

在很多 Go 编程书籍中，作者通常将数据访问逻辑放在处理业务逻辑的同一个函数中。虽然我知道这可能仅用于教学目的，但我想知道人们是否真的在现实世界的开发中将 BLL 与 DAL 分开。

我曾尝试将分层设计应用到我的 Go 项目中，但并没有感觉到任何好处。例如，我的 DAL 函数通常是这样的（在 appdal 包中）：

func GetCustomerAccountInfo (accountID int) (*sql.Rows, error) {
    sql := `SELECT * FROM CUSTOMER_ACCOUNT WHERE ID = $1`
    return GLOBAL_PSQL.Query(sql, accountID)
}

我典型的 BLL 函数是这样的：

func NewCustomerAccountBLL (accountID int) (* CustomerAccountBLL) {
    rows, err := appdal.GetCustomerAccountInfo(accountID)
    // create an instance of CustomerAccountBLL (bll) and scan rows....
    return &bll
}

我经常发现我的 BLL 本质上是与数据库模式耦合的，因为扫描要求我知道我的查询读取了哪一列，所以我发现将一些 DAL 函数合并到 BLL 中是一个不错的主意（例如将查询合并到 BLL反而）。此外，拥有 DAL 还会增加我必须维护的代码量。

然而，许多软件架构师也鼓励分层设计，拥有 BLL 和 DAL 并在每一层上分配明确的职责是有意义的。

虽然我也明白设计和模式不一定依赖于编程语言，但我经常发现在我的项目中同时使用 BLL 和 DAL 几乎没有什么好处。我是否遗漏了设计或 Go 中重要的东西？谢谢！

Answer 1

正如您所指出的，这个问题不是 Go 特定的，可以适用于任何语言。

以下是我认为您应该考虑的几点：

• 与其他设计问题一样，没有正确的方法可以做到这一点，但通常的做法是将业务逻辑与数据访问实际分开。

• 业务逻辑不应与实际的数据访问实现相关联，因此如果您随后决定放弃 SQL 并将对象保存在普通文件或 No-SQL 存储中，则您不一定需要更改业务逻辑层。

• 在您的情况下，GetCustomerAccountInfo返回sql.Rows. 这实际上将您的业务逻辑与该特定实现相结合。通常的做法是返回实际的模型对象（CustomerAccount例如 a）。

• 另请注意，您的示例非常简单，因此即使将其分开，您也可能看不到很多好处。但有时候事情并没有那么简单。

  • 数据访问逻辑可能涉及连接表的更复杂的查询，甚至在数据库事务中进行单独的查询。通过将其分开，您不会用这些低级细节污染业务逻辑。此外，您可以通过仅在数据访问层上进行更改来更改底层表结构，而无需更改业务逻辑层。

  • 业务逻辑也可能包含更复杂的计算，例如合并不同的对象、应用默认值和执行域验证。分离此逻辑（独立于所使用的存储）允许您更改业务逻辑，而不必更改数据访问逻辑。

基本上，通过将其分开，您可以分别开发（并且重要的是：测试）每个业务和数据访问逻辑，并具有更加模块化的设计。

我希望这有帮助。