オニオンアーキテクチャにConnectionStringを配置する場所

Question

私は、基本的にConnectionStringsをDatabase、Blob Storageなどのように保持するInterface IApplicationConfigを持っています。ウェブサイトやコマンドラインツールなど、私のソリューションのすべての「実行可能な」プロジェクトに対して、依存関係注入によって解決されるように設定されたそのインターフェースの具体的な実装があります。

私の質問は、これらをどこに置くのですか？IApplicationConfig -Implementations？

「実行可能」のプロジェクトごとにweb.config/app.configの横に表示されますか？ インフラストラクチャでは、Project1Config.cs,Project2Config.csなど？

Answer 1

はじめ

Iのいずれかで構成を管理実装した方法オニオン・アーキテクチャのルールに従って構築された私のアプリケーションは以下の通りです。

この特定のケースでは、インフラストラクチャ上の懸念事項として設定を管理することを検討しています。つまり、アプリケーションコアの一部ではないことを意味します。これは他のレイヤーであるためです。

理念コース下の図を見てご利用くださいインフラ懸念を実証するために：

_{* Shawn J Leeのブログからリンクされた画像。}

ここでは、ロギングがインフラストラクチャのスライスまたはレイヤーで行われていることがわかります。構成の管理もインフラストラクチャ上の問題であると述べています。

コンフィギュレーションマネージャの実装を保留する必要がある場合は、コンストラクタにIApplicationConfigを入力して、適切な実装を自分の好きなDI container/frameworkに設定してください。これはHollywood Principle以上、さらにはInversion Of Controlと呼ばれています。

あなたはあまり言いませんか？今度はあなたが実際の実装を置く場所について尋ねてきた技術のデモンストレーション...

実装の概要

にまっすぐに取得してみましょう。私はこれらのビットを構成します：

• アプリケーションコア層（単数または複数）
  • ドメインインターフェースアセンブリ
• インフラストラクチャ層
  • 構成アセンブリ
  • 依存解決アセンブリ
• UI層
  • コマンドラインアセンブリ
  • ウェブサイトアセンブリ

えっ眠く？今度はより高いギアに移行しよう。

実施例

私は短期的に、ここで実際の実装の詳細を説明しようとします。

ドメインインターフェースアセンブリ

これは、十分にはに対して動作または利用するようアプリケーション・コアは他の層 - およびすべてのインターフェイスを置く層です。

は、私たちがIApplicationConfig.csを持って言う：

public interface IApplicationConfig 
{ 
    ConnectionStringSettingsCollection GetConnectionStrings(); 
} 

設定アセンブリ

これはあなたのIApplicationConfigインタフェースの実際の実装（複数可）を持つことができる場所です。これを別のアセンブリとして扱うことは疑問ですが、実際は実装の詳細なので、ここに実装を管理するすべての設定を個人的に保存します。これは必要な実装とどこがあなたの「リンク」あなたのインターフェイスである

public class ApplicationConfig : IApplicationConfig 
{ 
    public ConnectionStringSettingsCollection GetConnectionStrings() 
    { 
     return ConfigurationManager.ConnectionStrings; 
    } 
} 

依存関係の解決アセンブリ

：ApplicationConfig.csとして

は、例えばIApplicationConfigの実装がある可能性があります。ここで私はNinjectを使用していますし、それがConfigModuleとしてそれを呼び出すためのNinject moduleを作成して、簡単な例：

public class ConfigModule : NinjectModule 
{ 
    Bind<IApplicationConfig>().To<ApplicationConfig>(); 
} 

そして最後にコマンド/ Webサイトのアセンブリ

通常、これらはComposition Rootかのエントリポイントですオブジェクトグラフを作成するアプリケーション。私たちは今、私たちのNinjectモジュールをロードする必要があり、この言った：あなたは

は、インターフェイス契約を持って、それは実装が分離だコマンド/ウェブサイトのアセンブリを追加する必要が

private static IKernel CreateKernel() 
{ 
    var kernel = new StandardKernel(); 

    var modules = new List<INinjectModule> 
     { 
      new ConfigModule(), 
      new WhateverModule(), 
      ... 
     }; 

    kernel.Load(modules); 
} 

参考文献を、ここであなただけへの参照を追加する必要があります：

• 依存解像度アセンブリ
• ドメインインターフェースアセンブリ

これで、必要なレイヤーで実装を使用できるようになりました。

あとがき

この例では、それが行うにはnot an easy thingだ...あなたは物事を命名に同意しない場合、私は同意し、私の実際のアプリケーションから撮影されています。

Answer 2

インターフェイスをより具体的にすることで、アプリケーションではなく特定のクラスやアセンブリに必要なものを指定することができます。データアクセスがそれ自身のアセンブリ内にある場合、ISettingsはそのアセンブリに固有であり、ホストアプリケーションとは共有されていない必要があります。次に、それを必要とするアセンブリに実装を配置します。ホストアプリケーションは、別のアセンブリで使用されているISettingsインターフェイスについて「認識」してはいけません。また、実装を作成または提供する責任を負いません。

実装がapp.config/web.configから読み取られる場合、これらの設定が不足していると、詳細な例外がスローされることを確認します。そうすれば、誰かがそのアセンブリに応じて、必要な設定を推測する必要がなくなります。

データアクセスアセンブリのDI構成は、データアクセスアセンブリまたは別のアセンブリ全体に存在する必要があります。ホストアプリケーションは、それらのアセンブリの詳細な登録が含まれていることを他のアセンブリについてあまり知る必要はありません。ホストアプリケーションは、そのアセンブリの依存関係を登録する外部インストーラを呼び出します。

DI構成を独自のアセンブリに配置することもできます。 （例：hereウィンザーを使用）このように、データアクセスアセンブリは依存性注入用に構築されていますが、いずれのDIコンテナにも依存しません。必要に応じて、必要に応じて、あなたは（自分の環境や行き過ぎ可能性が予想される使用に応じて。）などウィンザーインストーラ、Autofacインストーラを作成することができ