使用Grails環境特定配置的優點

我正在從傳統的Spring遷移到Grails，我對Grails per environment配置文件背後的邏輯感到困惑。我通常將環境感知代碼視爲反模式。有一個配置文件指定所有環境配置的原因是什麼，而不是爲每個環境配置不同的配置文件？使用Grails環境特定配置的優點

我看到的是，在這個Grails 的每個環境方法中，每個環境都有相同的配置文件，但是在運行時，您必須告訴應用程序它屬於哪個環境。這導致了代碼在執行中的行爲和代碼在測試中的行爲。

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框架中感到驚訝。

來源

2017-03-09 Usman Mutawakil

所以，你在這裏有很多問題，但問題的根源在於你的問題：「爲什麼在一個文件中有環境特定的配置設置？」

簡而言之，因爲它將所有配置保留在一個文件中，適用於所有環境。例如，您可以使用不同的SMTP服務器進行開發/測試/生產。而不是讓代碼圖表出來，它只是使用配置中定義的任何值。通過在單個文件中保持所有不同環境的設置，您可以輕鬆而均勻地查看它的內容。

如果您不需要，您不必在每個環境中使用一個環境。無論環境如何，您都可以使用應用程序。

單個文件避免了多個文件需要維護或確定在運行時加載哪一個文件。全都在一個地方。

我同意，具有特定環境的代碼是一個可怕的想法，應該避免。應該使用配置值（如上所述）。

來源

2017-03-09 21:22:11

使用Grails環境特定配置的優點

回答

相關問題