2017-07-19 19 views
0

現在、私は、Common.DLLという名前のDLLがあり、Unityによって登録が必要な新しいクラスを頻繁に更新する大きなプロジェクトに取り組んでいますDIの場合このDLLを参照し、新しいクラスがCommonで作成された場合は、この新しいタイプを登録するために必要なすべてが更新された独自のUnity構成ファイルを持つ3つの他のアプリケーション(Webサイト、WCFサービスなど)があります。共通ライブラリを参照している.NETアプリケーションのUnity登録の管理

明らかに、これは管理する苦痛であり、私はこのプロジェクトを継承しているので、このプロセスを簡単にする方法を考えています。 Common.DLLは確かにNugetパッケージに入れて配布することができます。

Common.DLLまたはCommon NuGetパッケージを新しいクラスで更新し、他のアプリケーションがCommon.DLL参照を変更したとき、またはその参照が変更されたときに、それらの登録を更新するよい方法を誰かが知っているかどうかは、パッケージが更新されます。どんなフィードバックも高く評価されます。ありがとう!

+0

各プロジェクトは、異なる方法でCommon.dllタイプを登録する必要がありますまたは登録が異なるプロジェクト間で一致しているしていますか? –

+0

一貫して、新しいクラスをCommonに追加し、そのクラスの登録を追加する必要があるとします。これは簡単ですが、アプリケーションを参照するたびに複数回実行する必要があります。 – forevermetal02

答えて

1

Commonのクラスはすべてのアプリケーションで同じ方法で登録されていると言われているので、Commonのすべてのクラスに対してプログラム登録を作成します。 Unityは、宣言的な設定とプログラム的なミキシングを可能にします。したがって、Common.dllコンポーネントはプログラムによって登録され、アプリケーション固有の登録(変更される可能性があります)はXML設定を使用して実行できます。

Common.dllの開発者に登録を作成する負担がかかります。なぜなら、クラスの登録方法を知っており、一度だけ(すべてのアプリケーションではなく)行う必要があるからです。更新があると、すべてのアプリケーションがコードを変更することなく登録変更を受け取ります。

Common.dllがUnityに直接依存しないようにするため、Common.Ioc.Unity.dllなどの登録用に別のアセンブリを作成し、Common.dllの登録をブートストラップする方法があります。例えば

さまざまなコンテナをサポートするために、さまざまな種類の登録を提供することもできます(必要な場合)。

欠点は、アプリケーションによっても参照される小さなアセンブリだということです。 Common.dllに類似したアセンブリが多数ある場合は、すべての共有登録を1つのアセンブリにまとめることについて考えるのは理にかなっています。

上記の別の(文体の)バリエーションは、コンテナ拡張を使用して登録を実装することです。たとえば、次のように

public class CommonContainerExtension : UnityContainerExtension 
{ 
    protected override void Initialize() 
    { 
     Container.RegisterType<Common.Logger>(new ContainerControlledLifetimeManager()); 
    } 
} 

次に、アプリケーションで使用して登録することができ:

var container = new UnityContainer(); 

// Register Common.dll using container extension or RegistrationManager 
container.AddNewExtension<CommonContainerExtension>(); 

// Register XML configuration for application 
// Application can even overwrite Common.dll registrations from above if required 
container.LoadConfiguration(); 
関連する問題