2012-03-14 8 views
0

私の設計については、適切かどうかは疑問です。 IoC autofacコンテナのXML構成でIoCコンテナを使用してServiceクラスのServiceConfigを解決する適切な設計

public class Service 
{ 
    private ServiceConfig Config { get; set; } 

    //inner class to store configuration 
    public class ServiceConfig 
    { 
    //a lot of configuration properties 
    } 

    //ctor - self resolve Config dependency - wondering whether this is very bad ? 
    public Service() 
    { 
    //get configuration class from IoC container - accessible as Singleton 
    Config = ContainerResolver.Instance().Resolve<Service.ServiceConfig>(); 
    } 

    //other code that provides functionality making use of Config property 
    //... 
} 

あなたは私が私の構成プロパティを維持するつもりだ内部ServiceConfigクラスがある見ることができるように私が登録し、それらのすべて:。

私はクラスを持っています。可能であれば、いくつかのOODの教祖がそれについていくつか言いたいと思います。

、 ルーク最初

+1

これは問題ですか? – Jodrell

+0

はい、私がしたことが良い習慣であるかどうかを知る必要があります。 – user1250785

+0

全体的な考え方は、ConfigurationクラスをSerivceクラスの依存関係として提供することです。コンフィグレーションクラスのプロパティ(ここには表示されません)は、コンテナコンフィグレーションに登録されています。構成クラスはコンテナによって解決される必要があります。 私の主な懸念事項は、サービスクラスのコンストラクタでConfigプロパティを解決することです。これが良い方法であるかどうかはわかりません。 – user1250785

答えて

1

は、はい、これは悪いデザインです。インスタンスが「ルート」である場合や、型がコンテナを介して簡単に解決できない場合にのみ、コンテナと直接対話する必要があります。ルートインスタンスは通常、スタートアップコードまたはブートストラップです。この場合

、あなたのコンテナが明確にすでに、なぜこのようにそれをしない、ServiceConfigを解決する方法を知っているので:

public class Service 
{ 
    private ServiceConfig Config { get; set; } 

    public class ServiceConfig 
    { 
    } 

    public Service(ServiceConfig serviceConfig) 
    { 
     Config = serviceConfig; 
    } 

    ... 
} 
関連する問題