Was Asp.net Core-Projekt für MicroService ohne Endpunkt

Question

Ich bin dabei, den Docker Sprung mit einem Microservices Framework zu nehmen. Ich habe zahlreiche Beispiele gesehen, die zeigen, dass ein Endpunkt von etwas angerufen wird, um etwas zu tun (bekomme das Wetter an einem Ort, den Wechselkurs für die Währung usw.). Ich habe nichts gesehen, das darüber redet, wie ich meine aktuellen Windows Service-Anwendungen oder Anwendungen, die Warteschlangen abonnieren, ersetzen kann, um ihre Arbeit zu erledigen.

Zum Beispiel, sagen wir, ich habe einen Windows-Dienst, der jeden Tag um 2:00 Uhr alle Dateien in einem bestimmten Verzeichnis reißt und sie in ein anderes Verzeichnis legt (dann veröffentlicht eine Nachricht, dass es abgeschlossen wurde).

Erstelle ich eine asp.net Core "Konsolen App" und füge ein startup.cs hinzu? Benötige ich eine startup.cs oder nur eine Startmethode in meiner Hauptversion?

Wie ich schon sagte, viele Demos zum Aufbau einer winzigen Web-Antwort, aber wenig darüber, was ich tun könnte, wenn ich nicht will/brauche und Endpunkt.

Answer 1

Startup.cs ist ziemlich ASP.NET Core-spezifisch, die an sich ist ein Web-Stack und kommt mit WebListener oder Kestrel gehostet hinter IIS.

In einer Konsolenanwendung würden Sie kein traditionelles Startup.cs verwenden, obwohl Sie eine konsistente Basis haben könnten, aber es würde ein bisschen anders aussehen, weil Sie die Kontrolle über die Erstellung des IoC Containers haben ASP.NET Core macht es für Sie in einer Webanwendung). Normalerweise wird das Startup.cs von der WebHostBuilder in Program.cs verarbeitet, damit es seine eigenen Sachen injizieren kann, bevor die IServiceCollection an die ConfigureServices Methode übergeben wird.

Sie haben recht, dass Sie eine Konsolenanwendung benötigen und dort würden Sie alles selber machen.

public class Program 
{ 
    public IConfigurationRoot Configuration { get; private set; } 
    public IServiceProvider Provider { get; private set; } 

    public static void Main() 
    { 
     var programm = new Programm(); 
     program.Run(); 
    } 

    private void Run() 
    { 
     var builder = new ConfigurationBuilder() 
      .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true) 
      .AddEnvironmentVariables(); 

     Configuration = builder.Build(); 

     var services = new ServiceCollection(); 
     ConfigureServices(services); 
     this.Provider = services.BuildServiceProvider(); 

     var host = this.Provider.GetRequiredService<MyHost>(); 
     // blocking operation, the host should be something that keeps the service running 
     // once it stops, the application stops too as there are no additional 
     host.Run(); 
    } 

    private void ConfigureServices(IServiceCollection services) 
    { 
     services.AddTransient<IMyService, MyService>(); 
     services.AddSingleton<MyHost>(); 
     ... 
    } 
} 

Was Sie als Host verwenden möchten, bleibt Ihnen überlassen. Es könnte das heißt einer Azure Web-Task/Host sein:

using(var jobHost = new JobHost(new JobHostConfiguration(Configuration.GetConnectionString("AzureWebJobsDashboard")))) 
{ 
    jobHost.RunAndBlock(); 
} 

, die die Anwendung laufen beginnen würde und halten und Azure-Nachrichten und Ereignisse in ihm registriert erhalten. Oder Sie verwenden einige der anderen Hintergrundaufgaben Frameworks wie Hangfire.

In ASP.NET Core all dies wird durch das Framework behandelt, aber ASP.NET Core ist für Web-Sachen gemacht und hängt daher von einem Endpunkt ab. Das meiste Zeug in Configure Methode der Startup Klasse in ASP.NET Core-Anwendung verwendet wird über die Registrierung von Middlewares, die auf der HttpContext arbeiten. Sie haben diese nicht in einem Microservice ohne einen Endpunkt. Kein Endpunkt, keine HttpContext, keine Notwendigkeit für Middleware.

Natürlich haben Sie auch keine IApplicationBuilder in einer Konsolenanwendung, nur eine IServiceProvider, um die Dienste zu lösen, die Sie zuvor registriert haben.