Umstellung nach DI bei Migration nach .NET Core, wie geht das?

Question

Hallo,
ich soll eine .NET Framework API nach .NET Core migrieren.
Dabei soll ich Umstellen auf DI.
So sieht der Code bisher aus:
(wobei myValue1 und myValue2, Variablen vom Typ eigener Klassen sind und myValue3 eine Variable vom Typ einer Microsoft-Klasse)

 public class MyClass : IMyClass
 {
	public MyClass()
        {
			myValue1 = new MyValue1(false);
			myValue2 = new MyValue2(myValue1);
			myValue3 = myValue2.GetInformation();
        } ...

Mein Problem beginnt damit, dass new MyValue1 ein Argument verlangt.
Das bekomme ich vielleicht noch so hin, dass ich schreibe:

 public class MyClass : IMyClass
 {
	public MyClass(MyValue1 myValue1)
        {
			myValue2 = new MyValue2(myValue1);
			myValue3 = myValue2.GetInformation();
        } ...

und in der Startup.cs dazu folgendes:

public class Startup
{ ...
	services.AddTransient<MyValue1>(ctx =>
            {
                IConfiguration configuration = ctx.GetRequiredService<IConfiguration>();
                return new MyValue1(false, configuration);
            }); ...

Dann  
1.) wird es kompliziert für mich und 
2.) gibt es bestimmt eine bessere Lösung hierfür.

Wer weiß wie dieses Problem zu lösen ist,
wie ich dies über DI Container auflösen kann (für .NET Core!)?

Danke, Frank

Answer 1

Hallo Frank,

ich weiß nicht so genau was Du eigentlich wissen willst. Ich versuche es mal trotzdem.

Ich nehme mal an Du meinst ASP.NET Core Web API? Wenn nicht um was für einen Projekttyp handelt es sich?

Hier mal ein einfache Beispiel zu DI

namespace WebApplication11
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            //Übergabe meiner Klasse an den Container
            services.AddSingleton(typeof(MyClass), new MyClass(true));
            
            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
        }

        //Hier bekomme ich MyClass in die Methode gereicht und kann sie nutzen.
        //Hier kann aber auch die erzeugte Klassen in Configure anderen Klassen zur verfügung stellen die nicht vom Container verwaltet werden
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, MyClass myClass)
        {
            
            if (myClass.GetMyVal() == true)
            {
                var la = "breakpoint";
            }

            new MyClass2(myClass);
            

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseMvc();
        }
    }

    public class MyClass
    {
        private bool _myVal = false;

        public MyClass(bool v)
        {
            _myVal = v;
        }

        public bool GetMyVal() => _myVal;
    }
}

---

Gruß Thomas
13 Millionen Schweine landen jährlich im Müll
Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings

Answer 2

Hallo Thomas,
ja, es handelt sich um eine ASP.NET Core Web API.
Der Punkt an dem ich arbeite ist, ich will den Konstruktor von MyClass mit einer DI versehen, so dass ich kein new ... (MyValue1 und MyValue2) im Konstruktor benötige.
Vielen Dank für die Unterstütztung!
Frank

Answer 3

Hallo Frank,

dazu hast Du 2 Möglichkeiten. Entweder der Container verwaltet deine Klasse und erzeugt sie wenn sie benötigt wird. In diesem Fall würde der Container die Abhängigkeiten an den Konstruktor übergeben. Wenn Du selbst die Klasse erzeugen willst und sie wird nicht vom Container verwaltet dann muss Du dich selbst darum kümmern die Abhängigkeiten an den Konstruktor zu übergeben.

Dependency Injection heißt ja einfach nur das man einer Klasse oder Methode alle Abhängigkeiten mitgibt. Ob nun durchs Framework aus einen Container oder selbst spielt dabei erstmal keine Rolle.

Container sind eigentlich eine ganz andere Geschichte. Container sind mit einer globalen statisch Liste vergleichbar in der alle Klassen sind die man für sein Projekt braucht. Das heißt das man am Anfang diese Liste erzeugt und sind dann nur noch aus ihr bedient. Container können aber noch mehr als eine statische Liste. An einen Container übergibt man nur den type einer Klassen. Der Container erzeugt die Klasse nur wenn sie wirklich gebraucht wird zudem gibt der Container Ressourcen wieder frei wenn sie nicht mehr gebraucht werden.

DI und Container haben den Anspruch die Architektur einer Anwendung zu vereinfachen. In dem man ganz am Anfang (Startup.cs) alle Abhängigkeiten dem Container mitteilt und allen Klassen ihr Anhängigkeiten mitgibt.

Mehr ist es auch nicht 

---

Gruß Thomas
13 Millionen Schweine landen jährlich im Müll
Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings