Question

我从传统的Spring转移到Grails，我对Grails per environment配置文件背后的逻辑感到困惑。我经常将环境感知代码视为反模式。使用单个配置文件指定所有环境的配置而不是为每个环境配置不同的配置文件的原因是什么？

我所看到的是，使用这种Grails per environment 方法，每个环境都有相同的配置文件，但在运行时，您必须告诉应用程序它属于哪个环境。这导致代码在prod中表现一种，在测试中表现另一种。

if(Environment == TEST){
//do something
}
if(Environment == PROD){
//do something that wasn't tested
}

是否有人使用这个，如果是这样，为什么不是每个环境只有一个不同的配置，而不是

dataSource {
    pooled = false
    driverClassName = "org.h2.Driver"
    username = "sa"
    password = ""
}
environments {
    development {
        dataSource {
            dbCreate = "create-drop"
            url = "jdbc:h2:mem:devDb"
        }
    }
    test {
        dataSource {
            dbCreate = "update"
            url = "jdbc:h2:mem:testDb"
        }
    }
    production {
        dataSource {
            dbCreate = "update"
            url = "jdbc:h2:prodDb"
        }
    }
}

你会有：

dataSource {
    pooled = false
    driverClassName = "org.h2.Driver"
    username = "sa"
    password = "Environment-Specific-Password"
    dbCreate = "create-drop"
    url = "jdbc:h2:mem:devDb"
}

然后，如果您不想在测试中运行某些内容，请在测试环境中的配置文件中禁用该功能。要重新讨论我的问题，明确地让应用程序环境意识到什么优势（如果有的话），这不是一个众所周知的坏主意吗？在Grails框架中有点意外。

Answer 1

所以，你在这里有很多问题，但问题的根源是你的问题＆＃34;为什么在一个文件中有特定于环境的配置设置？＆＃34;

简单地说，因为它将所有配置保存在一个文件中，适用于所有环境。例如，您可以使用其他SMTP服务器进行开发/测试/生产。而不是使代码形象出来只是使用配置中定义的任何值。将所有不同环境中的一个设置保存在一个文件中，可以让您轻松，统一地查看它的内容。

如果您不需要，您不必在每个环境中使用一个。无论环境如何，您都可以使用一个。

单个文件可避免维护多个文件或确定在运行时加载哪个文件。它在一个地方。

我同意，拥有环境特定的代码是一个可怕的想法，应该避免。应该使用配置值（如上所述）。

使用Grails环境特定配置的优点

1 个答案: