Sollen benutzerdefinierte ASP.NET Core-Optionen IOptions <> implementieren?

Question

Beim Durchsuchen der offiziellen Dokumentation zur ASP.NET Core-Konfiguration finden wir das folgende Beispiel. Dies ist auch in anderen Samples dominant.

public class MyOptions 
{ 
    public MyOptions() 
    { 
     // Set default value. 
     Option1 = "value1_from_ctor"; 
    } 
    public string Option1 { get; set; } 
    public int Option2 { get; set; } = 5; 
} 

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration

ich den ASP.NET Core-Caching Repo grast und bemerkte einen leichten Unterschied, wie das Microsoft-Team tut es.

public class MemoryCacheOptions : IOptions<MemoryCacheOptions> 
{ 
    // removed stuff 

    MemoryCacheOptions IOptions<MemoryCacheOptions>.Value 
    { 
     get { return this; } 
    } 
} 

https://github.com/aspnet/Caching/blob/dev/src/Microsoft.Extensions.Caching.Memory/MemoryCacheOptions.cs

Was ist der Vorteil von ioptions Umsetzung <>? Welche Art von "Magie" gibt es uns?

Answer 1

Nein, es ist nicht notwendig, die Schnittstelle zu implementieren. Soweit ich weiß, bietet es keinen Wert. Der meiste Code in der Klasse ist ziemlich alt (2-3 Jahre), also könnten es nur ein paar Reste einer früheren Optionseinführung sein. In der Tat, denke ich, dass es sicher entfernt werden kann.

Answer 2

Posted die Frage auf dem ASP.NET Core GitHub und bekam eine Antwort von einem der Entwickler. Durch die Implementierung von IOptions <> können Sie es einfacher in Komponententests verwenden, ohne dass die Options-Infrastruktur vorhanden ist.