HTTP und Weiterleitungen
Lassen Sie uns zunächst die Funktionsweise von ASP.NET MVC zusammenfassen:
- Wenn eine HTTP-Anforderung eingeht, wird sie mit einer Reihe von Routen abgeglichen. Wenn eine Route mit der Anforderung übereinstimmt, wird die der Route entsprechende Controller-Aktion aufgerufen.
- Vor dem Aufrufen der Aktionsmethode führt ASP.NET MVC eine Modellbindung durch. Bei der Modellbindung wird der Inhalt der HTTP-Anforderung, bei der es sich im Grunde nur um Text handelt, den stark typisierten Argumenten Ihrer Aktionsmethode zugeordnet
Erinnern wir uns auch daran, was eine Weiterleitung ist:
Eine HTTP-Umleitung ist eine Antwort, die der Webserver an den Client senden kann und die den Client auffordert, unter einer anderen URL nach dem angeforderten Inhalt zu suchen. Die neue URL ist in einem Location
Header enthalten, den der Webserver an den Client zurückgibt. In ASP.NET MVC führen Sie eine HTTP-Umleitung durch, indem Sie eine RedirectResult
von einer Aktion zurückgeben.
Daten übergeben
Wenn Sie nur einfache Werte wie Zeichenfolgen und / oder Ganzzahlen übergeben, können Sie diese als Abfrageparameter in der URL im Location
Header übergeben. Dies würde passieren, wenn Sie so etwas verwenden würden
return RedirectToAction("ActionName", "Controller", new { arg = updatedResultsDocument });
wie andere vorgeschlagen haben
Der Grund, warum dies nicht funktioniert, ist, dass XDocument
es sich um ein möglicherweise sehr komplexes Objekt handelt. Es gibt keine einfache Möglichkeit für das ASP.NET MVC-Framework, das Dokument in etwas zu serialisieren, das in eine URL passt, und dann die Modellbindung vom URL-Wert zurück zu Ihrem XDocument
Aktionsparameter zu modellieren .
Im Allgemeinen ist das Übergeben des Dokuments an den Client, damit der Client es bei der nächsten Anforderung an den Server zurückgeben kann, ein sehr spröder Vorgang: Es würde alle Arten von Serialisierung und Deserialisierung erfordern, und alle möglichen Dinge könnten schief gehen. Wenn das Dokument groß ist, kann dies auch eine erhebliche Verschwendung von Bandbreite darstellen und die Leistung Ihrer Anwendung erheblich beeinträchtigen.
Stattdessen möchten Sie das Dokument auf dem Server aufbewahren und eine Kennung an den Client zurückgeben. Der Client übergibt dann die Kennung zusammen mit der nächsten Anforderung und der Server ruft das Dokument unter Verwendung dieser Kennung ab.
Speichern von Daten zum Abrufen bei der nächsten Anforderung
Nun stellt sich die Frage, wo der Server das Dokument in der Zwischenzeit speichert. Nun, das müssen Sie entscheiden und die beste Wahl hängt von Ihrem speziellen Szenario ab. Wenn dieses Dokument auf lange Sicht verfügbar sein muss, können Sie es auf der Festplatte oder in einer Datenbank speichern. Wenn es nur vorübergehende Informationen enthält, ist es möglicherweise die richtige Lösung , diese im Speicher des Webservers, im ASP.NET-Cache oder im Session
(oder TempData
, was mehr oder weniger dem Session
am Ende entspricht) zu speichern . In beiden Fällen speichern Sie das Dokument unter einem Schlüssel, mit dem Sie das Dokument später abrufen können:
int documentId = _myDocumentRepository.Save(updatedResultsDocument);
und dann geben Sie diesen Schlüssel an den Client zurück:
return RedirectToAction("UpdateConfirmation", "ApplicationPoolController ", new { id = documentId });
Wenn Sie das Dokument abrufen möchten, rufen Sie es einfach anhand des Schlüssels ab:
public ActionResult UpdateConfirmation(int id)
{
XDocument doc = _myDocumentRepository.GetById(id);
ConfirmationModel model = new ConfirmationModel(doc);
return View(model);
}