-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Description
There is no information on this page about why the IOptions<T> interface exists, what purpose it serves, or why we should need to inject an IOptions<T> instance instead of a T instance for accessing configuration.
For comparison, a similar example in Java Spring Boot would look like this:
@ConfigurationProperties
public class PositionOptions
{
public string title;
public string name;
}
@Configuration
@EnableConfigurationProperties(PositionOptions.class)
public class MyAppConfiguration { }
public class Test2Model
{
public Test2Model(PositionOptions options) { }
}Note that the parameter to the model constructor is the type PositionOptions; there is no need for any wrapper type.
There just doesn't seem to be any value in wrapping the actual options type in IOptions<>. But I want to believe there is a rationale for this that I am missing, and I would love to see that rationale added to this page.
P.S. An issue was opened against the corresponding page for ASP.NET Core in November 2018 titled "Why should we use IOptions when we can inject the configuration object directly". There was some dicussion, and the issue was eventually closed after a docs update, "Emphasize IOptionsMonitor in Options topic + updates". It was a very large update, and there is no way for me to understand what part of that update was supposed to apply to that issue. But reading the page now, I don't see anything that addresses that issue's question.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
- ID: 433988ea-fda9-aa83-f6ee-221a5521a422
- Version Independent ID: 00449cdc-b8fc-a9ff-3f20-0ef0994db354
- Content: Options pattern in .NET
- Content Source: docs/core/extensions/options.md
- Product: dotnet-fundamentals
- GitHub Login: @IEvangelist
- Microsoft Alias: dapine