2017-02-02 14 views
4

私はASP.NET Coreを初めて使用しており、方向性が必要です。 Simple Injectorを使用しながらASP.NET Coreのアプリ設定を使用して簡単なシナリオを理解しようとしています。シンプルインジェクタでASP.NETコアアプリケーションの設定を使用するには

私は最初に、リック・ストラホルのhereで説明されているように強いタイプの構成設定をセットアップしました。これは素晴らしいです。

public class MySettings 
    { 
    public string ApplicationName { get; set; } 
    } 

appsetting.json

{ 
    "Logging": { 
    "IncludeScopes": false, 
    "LogLevel": { 
     "Default": "Debug", 
     "System": "Information", 
     "Microsoft": "Information" 
    } 
    }, 
    "MySettings": { 
    "ApplicationName": "Test Service" 
    } 
} 

Startup.cs

public void ConfigureServices(IServiceCollection services) 
    { 
     // Add framework services. 
     services.AddMvc(); 

     // Add Options 
     services.AddOptions(); 

     // Add our Config object so it can be injected 
     services.Configure<MySettings>(Configuration.GetSection("MySettings")); 
     services.AddSingleton(GetTestBroker(container)); 

     //Simple Injector  
     //services.AddSingleton<IControllerActivator>(new SimpleInjectorControllerActivator(container)); 
     //services.AddSingleton<IViewComponentActivator>(new SimpleInjectorViewComponentActivator(container)); 


    } 

当社の他のプロジェクトでDIのためのシンプルなインジェクターを使用していました。 Simple Injectorパッケージを追加して指示に従って設定すると、私のIOptions設定が破損することがわかります。

私が知りたいことは、ASP.NET Coreで設定を実装し、Simple Injectorのような別のDIライブラリを併用することがベストプラクティスとなることです。

+0

必要なものかどうIOptionsでの作業のベストプラクティスは、ここで説明されて見て見てみましょう:私が取るhttps://github.com/simpleinjector/SimpleInjector/issues/143#issuecomment-155029876 – Steven

+0

を一見。 – Eric

+0

@スティーブンその記事を見てみると、それは完全に合意です。次に、POCOをDIコンテナにシングルトンとして登録するだけです。あなたはこれで何を得ていたのですか? – Eric

答えて

2

ASP.NET Core integration guide for Simple Injector状態は次のとおりです。

ASP.NETコアはIOption<T>抽象化に基づいた新しい構成モデルが含まれています。アプリケーションコンポーネントにIOption<T>依存関係を注入しないことをお勧めします。代わりに、コンポーネントを構成オブジェクトに直接依存させ、シングルトンとして登録します。これにより、アプリケーションの起動時に構成値を確実に読み取って、その時点で検証して、アプリケーションのフェイル・ファーストを可能にします。

アプリケーションコンポーネントをIOptions<T>に依存させることは、不幸な欠点があります。まず第一に、アプリケーションコードがフレームワーク抽象化に不必要な依存性を持つようにします。これは、アプリケーションに合わせた抽象化の使用を規定するDependency Injection Principleの違反です。 IOptions<T>をアプリケーションコンポーネントにインジェクトすると、このコンポーネントはテストするのが難しくなりますが、メリットはありません。アプリケーションコンポーネントは、必要な構成値に直接依存する必要があります。

IOptions<T>設定値が遅延して読み込まれます。アプリケーションの起動時に構成ファイルが読み取られることがありますが、最初にIOptions<T>.Valueが呼び出された場合にのみ、必要な構成オブジェクトが作成されます。デシリアライズが失敗すると、アプリケーションの設定ミスのために、そのようなエラーはIOptions<T>.Valueへの呼び出し後にのみ表示されます。これにより、誤った設定が必要以上に長く検出されないことがあります。アプリケーションの起動時に設定値を読み取り、設定値を確認することで、この問題を防ぐことができます。構成値は、必要なコンポーネントにシングルトンとして注入できます。

特定のセクションを設定するのを忘れた場合(services.Configure<T>へのコールを省略)、設定セクションを取得している間に誤字を犯した場合(間違った名前をConfiguration.GetSection(name)に入力すると)例外をスローするのではなく、単にデフォルトの空のオブジェクトをアプリケーションに提供します。これは場合によっては意味をなさないかもしれませんが、容易に脆弱なアプリケーションにつながります。

起動時に構成を確認する必要があるため、読み込みを遅らせることは意味がなく、コンポーネントへのIOptionの注入が間違っています。依存する場合はに依存しますが、アプリケーションのブートストラップ時には有効ですが、それ以外の場合は依存関係にはなりません。

あなたが正しく読んで、構成オブジェクトを検証したら、設定オブジェクトを必要とするコンポーネントの登録は、このように簡単です:

MyMailSettings mailSettings = 
    config.GetSection("Root:SectionName").Get<MyMailSettings>(); 

// Verify mailSettings here (if required) 

container.Register<IMessageSender>(() => new MailMessageSender(mailSettings)); 
0

私はExistAll.SimpleConfigの著者です。 SimpleConfigはDI環境の設定/設定に必要なものです。

それはあなたが

関連する問題