services.Configure() or services.AddSingleton().Get()?
up vote
0
down vote
favorite
As known there are two ways to get option classes in ASP.NET Core 2:
Using
services.Configure<>()
like this:
services.AddOption();
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
or using
services.AddSingleton(Configuration.Get())
like this:
services.AddSingleton(Configuration.GetSection("applicationSettings")
.Get<ApplicationOptions>());
But what advantages or disadvantages do these different approaches have?
c# asp.net-core configuration
add a comment |
up vote
0
down vote
favorite
As known there are two ways to get option classes in ASP.NET Core 2:
Using
services.Configure<>()
like this:
services.AddOption();
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
or using
services.AddSingleton(Configuration.Get())
like this:
services.AddSingleton(Configuration.GetSection("applicationSettings")
.Get<ApplicationOptions>());
But what advantages or disadvantages do these different approaches have?
c# asp.net-core configuration
Read this and decide which you prefer simpleinjector.readthedocs.io/en/latest/…
– Nkosi
Nov 22 at 9:41
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
As known there are two ways to get option classes in ASP.NET Core 2:
Using
services.Configure<>()
like this:
services.AddOption();
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
or using
services.AddSingleton(Configuration.Get())
like this:
services.AddSingleton(Configuration.GetSection("applicationSettings")
.Get<ApplicationOptions>());
But what advantages or disadvantages do these different approaches have?
c# asp.net-core configuration
As known there are two ways to get option classes in ASP.NET Core 2:
Using
services.Configure<>()
like this:
services.AddOption();
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
or using
services.AddSingleton(Configuration.Get())
like this:
services.AddSingleton(Configuration.GetSection("applicationSettings")
.Get<ApplicationOptions>());
But what advantages or disadvantages do these different approaches have?
c# asp.net-core configuration
c# asp.net-core configuration
edited Nov 22 at 13:13
poke
206k44325383
206k44325383
asked Nov 22 at 5:47
ShefardPT
42
42
Read this and decide which you prefer simpleinjector.readthedocs.io/en/latest/…
– Nkosi
Nov 22 at 9:41
add a comment |
Read this and decide which you prefer simpleinjector.readthedocs.io/en/latest/…
– Nkosi
Nov 22 at 9:41
Read this and decide which you prefer simpleinjector.readthedocs.io/en/latest/…
– Nkosi
Nov 22 at 9:41
Read this and decide which you prefer simpleinjector.readthedocs.io/en/latest/…
– Nkosi
Nov 22 at 9:41
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
Short answer : The 1st way adds an Options
, and the 2nd way registers a plain singleton service.
I always prefer Options Pattern if possible.
Behind the scenes , the Configure<TOptions>()
will invoke services.AddSingleton<>()
to register a singleton service to configure options. However, To configure options, we should always use the 1st way. As the Configure<TOptions>(config)
(and all kind of other configure<>()
methods) will do all the heavy-lifting for us. :
For example, if we would like to store two different instance for the same type, how can we do that with a plain singleton service ? In fact, that' exactly what named options does.
Also, it hard to auto reload a plain singleton service according to a file change to
applicationSettings.json
.
Thanks a lot for the quite comprehesive answer!
– ShefardPT
Nov 22 at 10:26
add a comment |
up vote
0
down vote
Using Configure<ApplicationOptions>
allows the options pattern. The options pattern is a nice way to configure things using various configuration sources. In your example, you are configuring the ApplicationOptions
using a Microsoft.Extensions.Configuration source. But you can also configure it through other sources at the same time:
// configure using configuration
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
// then apply a configuration function
services.Configure<ApplicationOptions>(options =>
{
// overwrite previous values
options.Foo = "bar";
});
There are a few other ways to adjust the configuration as well, for example using post-configures which allows you to easily compose things that utilize options but may need to establish certain defaults or fallbacks.
Option objects will be configured at the time they are used, so when you call services.Configure()
, there is actually nothing being configured at that time. Instead, configurations are registered with the DI container. And then, when the options are resolved, all configurations for a certain type will be invoked (which allows for composition). This allows options to also support updating configuration; so when you update your appsettings.json
at run-time, options are able to receive the updated values.
In order to consume options, you need to inject IOptions<ApplicationOptions>
(or IOptionsSnapshot<ApplicationOptions>
if you need updating options). This is a wrapper around the options object which will invoke the options pattern.
On the other hand, calling AddSingleton<ApplicationOptions>
just registers a singleton instance as a fixed value. So what gets registered with the DI provider is whatever value Configuration.GetSection("applicationSettings").Get<ApplicationOptions>()
returns at that exact moment.
This has the benefit that you do not need to use the options pattern; instead of having to inject IOptions<ApplicationOptions>
into your types, you can just depend on ApplicationOptions
directly. So you don’t take a dependency on the Options framework. This is good for independent libraries that want to be used in different scenarios where the options pattern might not be available by default.
However, since this registers a fixed instance, you are also limited to those exact values. You cannot have those values update later when the configuration source is changed, and also cannot use that one configuration source in combination with other configurations.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Short answer : The 1st way adds an Options
, and the 2nd way registers a plain singleton service.
I always prefer Options Pattern if possible.
Behind the scenes , the Configure<TOptions>()
will invoke services.AddSingleton<>()
to register a singleton service to configure options. However, To configure options, we should always use the 1st way. As the Configure<TOptions>(config)
(and all kind of other configure<>()
methods) will do all the heavy-lifting for us. :
For example, if we would like to store two different instance for the same type, how can we do that with a plain singleton service ? In fact, that' exactly what named options does.
Also, it hard to auto reload a plain singleton service according to a file change to
applicationSettings.json
.
Thanks a lot for the quite comprehesive answer!
– ShefardPT
Nov 22 at 10:26
add a comment |
up vote
0
down vote
Short answer : The 1st way adds an Options
, and the 2nd way registers a plain singleton service.
I always prefer Options Pattern if possible.
Behind the scenes , the Configure<TOptions>()
will invoke services.AddSingleton<>()
to register a singleton service to configure options. However, To configure options, we should always use the 1st way. As the Configure<TOptions>(config)
(and all kind of other configure<>()
methods) will do all the heavy-lifting for us. :
For example, if we would like to store two different instance for the same type, how can we do that with a plain singleton service ? In fact, that' exactly what named options does.
Also, it hard to auto reload a plain singleton service according to a file change to
applicationSettings.json
.
Thanks a lot for the quite comprehesive answer!
– ShefardPT
Nov 22 at 10:26
add a comment |
up vote
0
down vote
up vote
0
down vote
Short answer : The 1st way adds an Options
, and the 2nd way registers a plain singleton service.
I always prefer Options Pattern if possible.
Behind the scenes , the Configure<TOptions>()
will invoke services.AddSingleton<>()
to register a singleton service to configure options. However, To configure options, we should always use the 1st way. As the Configure<TOptions>(config)
(and all kind of other configure<>()
methods) will do all the heavy-lifting for us. :
For example, if we would like to store two different instance for the same type, how can we do that with a plain singleton service ? In fact, that' exactly what named options does.
Also, it hard to auto reload a plain singleton service according to a file change to
applicationSettings.json
.
Short answer : The 1st way adds an Options
, and the 2nd way registers a plain singleton service.
I always prefer Options Pattern if possible.
Behind the scenes , the Configure<TOptions>()
will invoke services.AddSingleton<>()
to register a singleton service to configure options. However, To configure options, we should always use the 1st way. As the Configure<TOptions>(config)
(and all kind of other configure<>()
methods) will do all the heavy-lifting for us. :
For example, if we would like to store two different instance for the same type, how can we do that with a plain singleton service ? In fact, that' exactly what named options does.
Also, it hard to auto reload a plain singleton service according to a file change to
applicationSettings.json
.
answered Nov 22 at 9:56
itminus
2,6511320
2,6511320
Thanks a lot for the quite comprehesive answer!
– ShefardPT
Nov 22 at 10:26
add a comment |
Thanks a lot for the quite comprehesive answer!
– ShefardPT
Nov 22 at 10:26
Thanks a lot for the quite comprehesive answer!
– ShefardPT
Nov 22 at 10:26
Thanks a lot for the quite comprehesive answer!
– ShefardPT
Nov 22 at 10:26
add a comment |
up vote
0
down vote
Using Configure<ApplicationOptions>
allows the options pattern. The options pattern is a nice way to configure things using various configuration sources. In your example, you are configuring the ApplicationOptions
using a Microsoft.Extensions.Configuration source. But you can also configure it through other sources at the same time:
// configure using configuration
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
// then apply a configuration function
services.Configure<ApplicationOptions>(options =>
{
// overwrite previous values
options.Foo = "bar";
});
There are a few other ways to adjust the configuration as well, for example using post-configures which allows you to easily compose things that utilize options but may need to establish certain defaults or fallbacks.
Option objects will be configured at the time they are used, so when you call services.Configure()
, there is actually nothing being configured at that time. Instead, configurations are registered with the DI container. And then, when the options are resolved, all configurations for a certain type will be invoked (which allows for composition). This allows options to also support updating configuration; so when you update your appsettings.json
at run-time, options are able to receive the updated values.
In order to consume options, you need to inject IOptions<ApplicationOptions>
(or IOptionsSnapshot<ApplicationOptions>
if you need updating options). This is a wrapper around the options object which will invoke the options pattern.
On the other hand, calling AddSingleton<ApplicationOptions>
just registers a singleton instance as a fixed value. So what gets registered with the DI provider is whatever value Configuration.GetSection("applicationSettings").Get<ApplicationOptions>()
returns at that exact moment.
This has the benefit that you do not need to use the options pattern; instead of having to inject IOptions<ApplicationOptions>
into your types, you can just depend on ApplicationOptions
directly. So you don’t take a dependency on the Options framework. This is good for independent libraries that want to be used in different scenarios where the options pattern might not be available by default.
However, since this registers a fixed instance, you are also limited to those exact values. You cannot have those values update later when the configuration source is changed, and also cannot use that one configuration source in combination with other configurations.
add a comment |
up vote
0
down vote
Using Configure<ApplicationOptions>
allows the options pattern. The options pattern is a nice way to configure things using various configuration sources. In your example, you are configuring the ApplicationOptions
using a Microsoft.Extensions.Configuration source. But you can also configure it through other sources at the same time:
// configure using configuration
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
// then apply a configuration function
services.Configure<ApplicationOptions>(options =>
{
// overwrite previous values
options.Foo = "bar";
});
There are a few other ways to adjust the configuration as well, for example using post-configures which allows you to easily compose things that utilize options but may need to establish certain defaults or fallbacks.
Option objects will be configured at the time they are used, so when you call services.Configure()
, there is actually nothing being configured at that time. Instead, configurations are registered with the DI container. And then, when the options are resolved, all configurations for a certain type will be invoked (which allows for composition). This allows options to also support updating configuration; so when you update your appsettings.json
at run-time, options are able to receive the updated values.
In order to consume options, you need to inject IOptions<ApplicationOptions>
(or IOptionsSnapshot<ApplicationOptions>
if you need updating options). This is a wrapper around the options object which will invoke the options pattern.
On the other hand, calling AddSingleton<ApplicationOptions>
just registers a singleton instance as a fixed value. So what gets registered with the DI provider is whatever value Configuration.GetSection("applicationSettings").Get<ApplicationOptions>()
returns at that exact moment.
This has the benefit that you do not need to use the options pattern; instead of having to inject IOptions<ApplicationOptions>
into your types, you can just depend on ApplicationOptions
directly. So you don’t take a dependency on the Options framework. This is good for independent libraries that want to be used in different scenarios where the options pattern might not be available by default.
However, since this registers a fixed instance, you are also limited to those exact values. You cannot have those values update later when the configuration source is changed, and also cannot use that one configuration source in combination with other configurations.
add a comment |
up vote
0
down vote
up vote
0
down vote
Using Configure<ApplicationOptions>
allows the options pattern. The options pattern is a nice way to configure things using various configuration sources. In your example, you are configuring the ApplicationOptions
using a Microsoft.Extensions.Configuration source. But you can also configure it through other sources at the same time:
// configure using configuration
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
// then apply a configuration function
services.Configure<ApplicationOptions>(options =>
{
// overwrite previous values
options.Foo = "bar";
});
There are a few other ways to adjust the configuration as well, for example using post-configures which allows you to easily compose things that utilize options but may need to establish certain defaults or fallbacks.
Option objects will be configured at the time they are used, so when you call services.Configure()
, there is actually nothing being configured at that time. Instead, configurations are registered with the DI container. And then, when the options are resolved, all configurations for a certain type will be invoked (which allows for composition). This allows options to also support updating configuration; so when you update your appsettings.json
at run-time, options are able to receive the updated values.
In order to consume options, you need to inject IOptions<ApplicationOptions>
(or IOptionsSnapshot<ApplicationOptions>
if you need updating options). This is a wrapper around the options object which will invoke the options pattern.
On the other hand, calling AddSingleton<ApplicationOptions>
just registers a singleton instance as a fixed value. So what gets registered with the DI provider is whatever value Configuration.GetSection("applicationSettings").Get<ApplicationOptions>()
returns at that exact moment.
This has the benefit that you do not need to use the options pattern; instead of having to inject IOptions<ApplicationOptions>
into your types, you can just depend on ApplicationOptions
directly. So you don’t take a dependency on the Options framework. This is good for independent libraries that want to be used in different scenarios where the options pattern might not be available by default.
However, since this registers a fixed instance, you are also limited to those exact values. You cannot have those values update later when the configuration source is changed, and also cannot use that one configuration source in combination with other configurations.
Using Configure<ApplicationOptions>
allows the options pattern. The options pattern is a nice way to configure things using various configuration sources. In your example, you are configuring the ApplicationOptions
using a Microsoft.Extensions.Configuration source. But you can also configure it through other sources at the same time:
// configure using configuration
services.Configure<ApplicationOptions>(Configuration.GetSection("applicationSettings"));
// then apply a configuration function
services.Configure<ApplicationOptions>(options =>
{
// overwrite previous values
options.Foo = "bar";
});
There are a few other ways to adjust the configuration as well, for example using post-configures which allows you to easily compose things that utilize options but may need to establish certain defaults or fallbacks.
Option objects will be configured at the time they are used, so when you call services.Configure()
, there is actually nothing being configured at that time. Instead, configurations are registered with the DI container. And then, when the options are resolved, all configurations for a certain type will be invoked (which allows for composition). This allows options to also support updating configuration; so when you update your appsettings.json
at run-time, options are able to receive the updated values.
In order to consume options, you need to inject IOptions<ApplicationOptions>
(or IOptionsSnapshot<ApplicationOptions>
if you need updating options). This is a wrapper around the options object which will invoke the options pattern.
On the other hand, calling AddSingleton<ApplicationOptions>
just registers a singleton instance as a fixed value. So what gets registered with the DI provider is whatever value Configuration.GetSection("applicationSettings").Get<ApplicationOptions>()
returns at that exact moment.
This has the benefit that you do not need to use the options pattern; instead of having to inject IOptions<ApplicationOptions>
into your types, you can just depend on ApplicationOptions
directly. So you don’t take a dependency on the Options framework. This is good for independent libraries that want to be used in different scenarios where the options pattern might not be available by default.
However, since this registers a fixed instance, you are also limited to those exact values. You cannot have those values update later when the configuration source is changed, and also cannot use that one configuration source in combination with other configurations.
answered Nov 22 at 13:11
poke
206k44325383
206k44325383
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53424593%2fservices-configure-or-services-addsingleton-get%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Read this and decide which you prefer simpleinjector.readthedocs.io/en/latest/…
– Nkosi
Nov 22 at 9:41