DotNetCore跨平臺~配置文件與配置代碼如何共存
阿新 • • 發佈:2017-10-14
html sta tty dock lin json ogg null pps
回到目錄
古人雲《一山不容二虎》,而進行dotnet core時代之後,我們可以看到這樣的一些官方的DEMO,它將數據連接串和其它配置項都直接硬編碼在代碼裏,即在startup中進行定義,試問你在生產環境如何兼容!當然,你會說,可以在對應appsettings裏進行配置,說它是對應的appsettings,是因為dotnet core下的配置文件有環境的區分,一般使用以下名稱來表示不同的環境:
- 開發環境,Development
- 預發布環境,Staging
- 生產環境,Production
對於二者,配置文件和硬編碼配置如何進行選擇,如果兩者都設置了,那到底應該以誰為準呢?大叔認為,如果二者都設置了,那以配置文件為準,當配置文件沒有定義時,再以硬編碼配置為準,這就是他們的優先級,原因有下面幾點:
- 硬編碼方便在開發環境去調試
- 在指定運行環境後,配置文件根據環境的不同,選擇不同的配置
- 優化級,配置文件 優於 硬編碼
下面是倉儲服務在註冊時,選擇配置的策略,當然,你可以把這種邏輯做成一種裝飾,感覺更好。
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文件進行加載!
感謝咱們閱讀!
回到目錄
DotNetCore跨平臺~配置文件與配置代碼如何共存