Kann ein zuverlässiger Dienst auch direkt RESTful sein (kein separater owinbasierter Controller) in Service Fabric?

Question

Visual Studio 2015 Update 2 bietet eine Vorlage zum Erstellen von owinbasierten Controllern in der Service Fabric. Die erstellte Struktur zeigt Ihnen einen zustandslosen zuverlässigen Dienst und den owin-basierten Controller als 2 verschiedene C# -Klassen. Das funktioniert. In diesem Fall registriert die zuverlässige Serviceklasse einfach einen HTTP-Listener und alle Anrufe werden an die Controller-Klasse weitergeleitet. In gewisser Weise ist der zustandslose zuverlässige Dienst sofort nach der Erstellung aus dem Bild und nur während der Inbetriebnahme des Dienstes nützlich.

Ich erwartete einen zuverlässigen Service und die owin-basierte Steuerung, ein und dasselbe. Die derzeitige Struktur scheint wie eine Patch-Arbeit.

Wenn ich den zustandslosen zuverlässigen Dienst zu einem zustandsabhängigen zuverlässigen Dienst ändern würde, kann ich mit dem zustandsbehafteten Dienst nicht wirklich etwas anfangen, da meine Anforderungen an den Controller weitergeleitet werden. Wenn ich in meinem Controller mit dem State Manager interagieren würde, dann müsste ich den Verweis auf den Stateful Service bekommen und dann meine Sachen machen. Fühlt sich unbeholfen an.

Gibt es eine sauberere Möglichkeit, dies zu tun?

Answer 1

Der Service ist Ihr Anwendungscontainer. Die Service-Basisklassen (StatefulService und StatelessService) sind Ihre Einstiegspunkte für Ihre Anwendung. Sie können direkt in diesen Klassen an einer Party teilnehmen und haben Ihren gesamten Code dort oder Sie können diesen Einstiegspunkt verwenden, um ein anderes Anwendungsframework wie ASP.NET MVC oder Reliable Actors oder was auch immer zu booten. Service Fabric stellt alle Ihre Plattformabhängigkeiten über die Service-Basisklassen zur Verfügung (z. B. ServiceContext, IReliableStateManager für Stateful-Services usw.) und Sie können sie entweder direkt in diesen Klassen verwenden, wenn sich Ihr Code dort befindet, oder Sie können diese Abhängigkeiten übergeben zusammen mit einem anderen Anwendungsrahmen.

Für ASP.NET verwenden wir den Service zum Bootstrapping eines OWIN-basierten Webservers (Katana, Kestrel, WebListener), dem wir dann Anwendungs-Middleware (MVC, StaticFiles usw.) zur Verfügung stellen. Sie können dann alle Plattformabhängigkeiten an die Middleware übergeben, indem Sie Ihr bevorzugtes Abhängigkeitsinjektions-Framework verwenden (Unity, Autofac, Ninject oder das integrierte Framework für die Abhängigkeitsinjektion von ASP.NET Core). Hier

ist ein Beispiel für einen Stateful-Dienst, der dies tut, mit Unity und Katana: https://github.com/Azure-Samples/service-fabric-dotnet-getting-started/tree/master/Services/WordCount/WordCount.Service