.NET アプリの構成を環境中立にするためのベスト プラクティスについて考えてみたいと思います。
バックグラウンド。最初にいくつかの背景。私は .NET の世界ではなく、Java の世界から来ました。Java では、環境に依存しないパッケージを構築するためにできることがいくつかあります。それらは通常、何らかの方法で構成を抽象化することに基づいています。以下にいくつかの例を示します。
- JNDI を使用すると、アプリはエンタープライズ リソース (データベース、JavaMail セッション、JCR リポジトリなど) を名前で参照でき、その名前は環境 (dev、test、prod) に従って特定の構成にマップされます。
- もう 1 つの例は、プロパティ ファイルです。アプリの起動時に既知の場所にあるプロパティ ファイルからアプリが取得する一連のプロパティ (「encryption_key」、「smtp.server.url」、「admin.email」など) がある場合があります。プロパティ キーは、環境に応じて異なる値にマップされます。
- 一部のアプリ開発フレームワーク (Spring など) は、プロパティ ファイルをプルする方法を知っているため、プロパティをフレームワーク構成と統合できます。
私が Java で見たもう 1 つのアプローチはビルド時アプローチで、Ant (トークン置換) または Maven (ビルド プロファイル) を使用して環境固有のパッケージをビルドします。テストと本番用にまったく同じパッケージをデプロイすることを強く好むという理由だけで、このアプローチはあまり好きではありません。しかし、それは私が見たアプローチです。
望ましい解決策。.NET には、その環境から構成 (および拡張により、含まれているパッケージ) を分離するためのいくつかの同等の戦略があると想定しています。
理想的には、環境以外の構成をアプリに密接に関連付けて、環境のみを外部化できるソリューションが必要です。Java の例に戻ると、多くの場合、「構成」は実際には開発者が制御するものです。たとえば、ページ装飾用の Sitemesh サーブレット フィルター、依存性注入またはアプリ ワイヤリング、およびそのような MVC コントローラー メソッドのマッピングなどです。リクエストURIなどに。外部化されたくないもの。しかし、暗号化キー、DB 接続文字列、ログ レベルなどはそうです。