Laden...

ASP.NET Core - Funktion aufrufen ohne Rückgabe einer View möglich ?

Erstellt von fahrer vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.918 Views
F
fahrer Themenstarter:in
4 Beiträge seit 2019
vor 5 Jahren
ASP.NET Core - Funktion aufrufen ohne Rückgabe einer View möglich ?

Hallo,

ich habe SPA unter MVC zum ausprobieren am laufen, ist es irgendwie möglich
eine Funktion aufzurufen ohne das ich eine View zurück geben muss, sprich
die aktuelle View soll einfach stehen bleiben ?

Es sollen im Hintergrund lediglich ein paar Zahlen aus dem Internet ausgelesen werden,
wenn dabei ein Fehler auftritt, im Moment mache ich das so:

public async Task<IActionResult> HoleZahlen()

        {
}

Hier arbeitet er ja die Funktion ab und am Ende muss ich eine View zurück geben,
habe ich auch eine Möglichkeit einfach nur eine Funktion aufzurufen ohne eine
View zurück geben zu müssen ?

Habe mal ein wenig C# gelernt, ist aber schon einige Jahre her und versuche grade mir Core mal anzuschauen.

5.658 Beiträge seit 2006
vor 5 Jahren

Ja, das nennt sich ASP.NET WebAPI. Das kann zusammen mit MVC oder auch ohne verwendet werden. Zurückgegeben wird ein JSON-Objekt, welches deine Zahlen enthält.

Weeks of programming can save you hours of planning

F
fahrer Themenstarter:in
4 Beiträge seit 2019
vor 5 Jahren

Danke, und wenn ich wirklich nur eine Funktion auf dem Server "anstossen" möchte,
dann werte ich das JSON einfach nicht aus bspw. oder gibts für den Fall noch bessere
Wege ?

1.029 Beiträge seit 2010
vor 5 Jahren

Hi,

grundlegend: Wenn du keinen Input brauchst - braucht deine Methode auch kein JSON/Input - also geht eine Methode à la:


public IActionResult DoYourThing()
{
// do your thing
return Ok();
}

Allerdings musst du aufpassen - WebRequests haben ein Timeout - wenn du dieses nicht beachtest - bricht dir sowas auch leicht mal ab - falls das ein Problem ist - solltest du dir mal folgendes anschauen:
https://blogs.msdn.microsoft.com/cesardelatorre/2017/11/18/implementing-background-tasks-in-microservices-with-ihostedservice-and-the-backgroundservice-class-net-core-2-x/

Alternativ kann man auch die Timeouts anpassen, siehe:
https://stackoverflow.com/questions/37474309/timeouts-with-long-running-asp-net-mvc-core-controller-httppost-method

LG

16.834 Beiträge seit 2008
vor 5 Jahren

Es ist eine Methode, keine Funktion. Funktionen sind was anderes.
Im Sinne von ASP.NET spricht man hier aber spezifisch von einer Action; im Sinne des API Designs spricht man von einer Operation.
Aber niemals von einer Funktion.

Fire-and-Forget gibt es bei HTTP an für sich nicht wirklich.
Ein Client wartet per default immer auf ein Result - und kann dann auch wie Taipi schon sagte in einem Timeout enden, obwohl einem die Antwort "egal" ist.

Operations mit sendendem Charakter (wie es in Deinem Fall so ist, Du willst etwas auf dem Server ausführen) sollten via POST Method ausgeführt werden.

F
fahrer Themenstarter:in
4 Beiträge seit 2019
vor 5 Jahren

@ Abt

Soweit verstanden, sorry für die falschen Bezeichnungen, was wäre denn aus deiner
Sicht der vernünftigste bzw. einfachste Weg für eine Progress Bar, die eingeblendet
werden soll und der ich die aktuelle %Zahl übergeben möchte ?

Den Weg an sich habe ich gefunden und über ViewBag realisert.

Da ich die Operation, die die Zahlen holt ja in einem async Task laufen lasse,
blockiert die Webseite ja so lange bis sie alle Zahlen hat, da in dieser Funktion auch
die % Zahl der Progreessbar verändert wird, wird ja diese in der View auch erst dann "aktualisiert" wenn alle Zahlen da sind, so sieht der User ja aber keinen Fortschritt, sondern nur nach 20 Sekunden ca. das 100 % da sind....

Fire und Forget mit Hangfire oder ähnlichem erscheint mir für sowas überdimensioniert,
oder ist das nur so möglich ?

Bin da für Ideen offen !?

W
955 Beiträge seit 2010
vor 5 Jahren

Wenn alles in einem Aufruf erwartet wird hast du keine Chance zwischendurch den Fortschritt anzuzeigen. Du benötigst eine bidirektionale Verbindung womit der Server den Abarbeitungsfortschritt mitteilen kann. Du könntest SignalR dafür verwenden.

F
fahrer Themenstarter:in
4 Beiträge seit 2019
vor 5 Jahren

Hm, ok wenn mir da nichts anders übrig bleibt, gehe ich da mal bei und schau mir das mal an, aber
das ist ja Wahnsinn für eine ja eigentlich relativ simple Progress Bar ?

16.834 Beiträge seit 2008
vor 5 Jahren

Das ist relativ.
Das Web arbeitet prinzipiell mit einem verbindungslosen Protokoll namens HTTP - solche Basics brauchst Du.
Ergo gibt es nach einem Request keinerlei Datenaustausch zwischen Server und Client und damit natürlich auch kein Informationsaustausch für eine Progressbar.

Eine Progressbar erfordert eine pro-aktive Verbindung vom Server zum Client, also eine Push Nachricht.
Dafür ist HTTP aber nicht gedacht. Daher gibt es Technologien wie Websockets, mit dem eine Information vom Server zum Client durch eine dauerhafte TCP Verbindung gewährleistet werden kann.

Eine Webanwendung besteht aus vielen Komponenten, kommuniziert i.d.R. über verschiedene Protokolle und ist wesentlich komplexer als Desktop-Anwendungen.
Wenn Du versuchst dies zu vergleichen, dann bist Du auf dem absoluten Holzweg 😉

Da ich die Operation, die die Zahlen holt ja in einem async Task laufen lasse,
blockiert die Webseite

Nein, async/await hat hier nichts mit einer blockierenden Antwort zutun.
Da vermischt Du so ziemlich alles, was man hier vermischen kann 😉

async/await ist eine reine In-Process Angelegenheit und dient dazu die Ressourcen auf einem System effizienter zu nutzen (sehr vereinfacht gesagt).
Das hat aber nichts damit zutun, wie HTTP funktioniert.

Fire und Forget mit Hangfire oder ähnlichem erscheint mir für sowas überdimensioniert,
oder ist das nur so möglich ?

Keine Ahnung, wie Du nun auf Hangfire kommst - aber Hangfire hat in diesem Zusammenspiel überhaupt keine Aktien.
Fire and Forget ist eine allgemeine Bezeichnung bzw Technik - aber ja, sowas gibts in Hangfire auch (wie in 97434 Millionen anderen Implementierungen auch).

Fire and Forget heisst einfach nur: Anfrage abschicken, der Rest ist mir egal.