Laden...

Interface in Konstruktor wird von DI nicht gefunden

Erstellt von JimStark vor 3 Jahren Letzter Beitrag vor 3 Jahren 963 Views
JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren

Hi Leute,

da es hier schon um Services ging will ich anschließen:


            services.AddScoped<ISettings>(_ => new ConfigurationBuilder<ISettings>()
                .UseEnvironmentVariables()
                .Build()
            ) ;

            // Add ERP Manager
            services.AddScoped<IErpManager, ErpManager>();


        public ErpManager(ISettings settings)

Die ERPManager Klasse erwartet im Konstruktur ein ISettings Objekt.
Der Manager wird dem Controller übergeben, wenn ich es debugge sieht man aber das der Code im Konstruktur des ErpManagers nicht ausgeführt wurde. (Einstellungen wurde nicht übernommen,...)

Übersehe ich da was oder geht das wegen dem Interface nicht?

16.806 Beiträge seit 2008
vor 3 Jahren

So funktionieren die Settings bzw. der Config Builder nicht.
Schau Dir dazu den Option Pattern in den Docs an, und wie die Quelle erzeugt wird.

JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren

Also der obere Teil funktioniert so recht gut, da bekomme ich die ISettings in den Controller übergeben und kann darauf zugreifen.

Ich versteh nur nicht wieso das Interface dem Konstruktur nicht übergeben wird. Muss ich da wieder einen Umweg über einen extra Service gehen?

16.806 Beiträge seit 2008
vor 3 Jahren

Das Problem ist, dass Du einfach nicht machst, wie es gedacht ist.
Ich weiß nicht ob es daran liegt, weil Du einfach keine große Lust hast das richtig zu machen, weil Du irgendeinen anderen speziellen Plan hast oder einfach keine Zeit hast die Docs zu lesen, um es zu verstehen.
Du bastelst zuviel - und das ist halt nicht so praktisch 😉

Die Konfigurationspipeline bei .NET Applikationen rennt vor dem Startup.
Bei Konsolenanwendungen (wozu auch ASP.NET Core gehört) im Rahmen der Program.cs.

Das Ergebnis des Config Setups bekommst Du als IConfigurationRoot Parameter in die Startup Klasse übergeben.
Das zeigen alle, wirklich alle Docs und Samples von Microsoft auch so. ⚠

Was Du machst ist die Config Pipe (implizit) laufen zu lassen, springst ins Startup und machst dann nochmal das Config Setup explizit. Warum? Wo ist der Sinn?
Es wirkt nicht, dass Du irgendwie weißt, was passiert und was Dein Code wirklich macht.
Daher entsprechend auch meine kurze Antwort im letzten Beitrag.

Zu 99,9% wird das ein Folgefehler sein, weil Du einfach das Zeug nicht so machst, wie es in den Docs gezeigt wird (und technisch funktioniert). 😉

JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren

Ist Config.Net nicht genau dafür da? Also das ich die App.config einlesen kann aber auch andere Quellen?
Sollte die auch in Program.cs mit rein?

16.806 Beiträge seit 2008
vor 3 Jahren

Und warum meinst Du ein externes Konfigurationsframework verwenden zu müssen, wenn Du ein vollständiges, modernes Framework mit Microsoft.Extensions.Options mit an Bord hast, das Teil der gesamten ASP.NET Core Pipeline ist?
Welche Anforderung hast Du denn, dass die eingebauten Options nicht funktionieren?

Config.NET hat eine Berechtigung in der alten Welt; weniger in der neuen Welt.
Aber.. ja.. im Endeffekt das was ich im letzten Beitrag ausgesagt hab: Du hast Dich nie wirklich damit beschäftigt, richtig?

So hast Du jetzt eben zwei konkurrierende Konfigurationspipelines in Deiner Anwendung laufen.
Kann man machen....

Aber wenn die Config durchläuft, dann sollte das DI ziehen.
Scoped macht bei Settings aber keinen Sinn: hab nich umsonst auf den Option Pattern verwiesen.

JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren

Ja so sehr habe ich mich noch nicht damit beschäftigt, da ich noch ziemlicher ASP Anfänger bin und das von WinForms, etc. noch gewohnt bin.

Also wäre es deiner Meinung der eleganterer Weg z.B. so vorzugehen:


    services.Configure<PositionOptions>(Configuration.GetSection(
                                        PositionOptions.Position));

Und die Konfiguration im Manager so auszulesen:


ErpManager(IOptions<PositionOptions> options)

Oder?
Trotzdem komisch wieso er den Konstruktur mit dem Interface nicht ausgeführt hat, ohne das Interface als Parameter ging es. Per DI konnte ich trotzdem darauf zu greifen.

Aber ich denke dann werde ich von Config.Net komplett auf den eingebauten wechseln.

16.806 Beiträge seit 2008
vor 3 Jahren

Ich erinner dich bestimmt zum 7-8 mal dran, aber ohne Dich damit zu beschäftigen wirst Du dauernd stolpern.
ASP.NET Core funktioniert nicht ansatzweise wie Desktop-Applikationen: das ist eine völlig andere Welt.