小编fal*_*way的帖子

我目前正在golang(与Gorilla)构建一个Web应用程序,并实现了一些API端点.但是,我注意到每次实现类似的功能

func CreateUserHandler(w http.ResponseWriter, r *http.Request) {}

我必须将下面的函数添加到处理函数体中以检查请求是否被授权:

func checkAuthorizedUser (r * http.Request) error {
    uid, err := CheckRequestUser (r.Cookie("uid"))
    if err != nil {
        return errors.New("Can't find cookie value for uid")
    }
    if !IsValidUser (uid.Value) { 
        return errors.New("Not a valid user")
    }
    return nil
}

我现在发生的事情是我必须添加checkAuthorizedUser()到每个处理函数,到目前为止我已经有很多处理函数.我想知道是否有更好的方法来检查客户端是否有权访问某个端点,而不是在每个处理函数中显式检查身份验证.

在很多 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 和 …