回到目錄

古人云《一山不容二虎》，而進行dotnet core時代之後，我們可以看到這樣的一些官方的DEMO，它將資料連線串和其它配置項都直接硬編碼在程式碼裡，即在startup中進行定義，試問你在生產環境如何相容！當然，你會說，可以在對應appsettings裡進行配置，說它是對應的appsettings，是因為dotnet core下的配置檔案有環境的區分，一般使用以下名稱來表示不同的環境：

1. 開發環境，Development
2. 預釋出環境，Staging
3. 生產環境，Production

對於二者，配置檔案和硬編碼配置如何進行選擇，如果兩者都設定了，那到底應該以誰為準呢？大叔認為，如果二者都設定了，那以配置檔案為準，當配置檔案沒有定義時，再以硬編碼配置為準，這就是他們的優先順序，原因有下面幾點：

1. 硬編碼方便在開發環境去除錯
2. 在指定執行環境後，配置檔案根據環境的不同，選擇不同的配置
3. 優化級，配置檔案 優於 硬編碼

配置檔案可能是這樣（Production和Staging環境）,一般development不需要配置，直接寫在程式碼裡就行了，除錯方便！

 程式中直接使用配置可以是這樣(Development環境)

核心的配置策略實現部分

下面是倉儲服務在註冊時，選擇配置的策略，當然，你可以把這種邏輯做成一種裝飾，感覺更好。

public class EFOptionsExtension : ILindOptionsExtension
    {
        
 
private readonly Action<RepositoryOptions> _configure;

        public EFOptionsExtension(Action<RepositoryOptions> configure)
        {
            _configure = configure;
        }
        public void AddServices(IServiceCollection services)
        {
            var options = new
 
 EFOptions();
            _configure?.Invoke(options);//裝飾
            if (oConfigFileHelper.Get<EFOptions>().ConnString != null) //配置檔案優先硬編碼
            {
                options.ConnString = ConfigFileHelper.Get<EFOptions>().ConnString;
            }
            if (ConfigFileHelper.Get<EFOptions>().DbType != DbType.None)
            {
                options.DbType = ConfigFileHelper.Get<EFOptions>().DbType;
            }
            services.AddSingleton<ILogger, FileLogger>();//日誌
            services.AddSingleton(options);//ef配置
            services.AddTransient(typeof(DbContext), options.DbContextType);//註冊資料上下文，例項模式
            services.AddTransient(typeof(IRepository<>), typeof(EFRepository<>));//註冊資料倉儲
        }
    }

在我們進行釋出之後，一般把dotnet core釋出到linux或者直接放在docker容器裡執行，這時只要設定對應的環境變數即可，非常方便！

ENV ASPNETCORE_ENVIRONMENT="Production"

設定完成後，dotnet core會自己選擇對應的appsettings.Production.json檔案進行載入！

感謝咱們閱讀！

回到目錄