Best Practices für die Übergabe von Daten von asp.net-mvc an Javascript

Lesezeit: 4 Minuten

Ich habe in letzter Zeit viel mit ASP.NET MVC und Javascript/jQuery gearbeitet und ich scheine in eine Richtung zu gehen, in der ich immer einen dynamischen Wert “an” mein Javascript übergeben muss. Wenn das Skript direkt auf der Seite ist, habe ich so etwas gemacht:

var isEditable = <%=ViewData["editable"]%>

Mir gefällt, dass dies schnell und einfach ist und genau so, als würde ich einen Wert in HTML einfügen. Aber das riecht. Wirklich, wirklich schlecht. Und es unterbricht die Intellisense- und Codeformatierung von Visual Studio, wodurch meine Skripts schwer lesbar und verständlich werden.

Mir ist aufgefallen, dass eine andere Lösung darin besteht, meine Daten an ein verstecktes Feld zu übergeben und die Javascript-Referenz zu haben, die …

<input type="hidden" id="editable" value="<%=ViewData["editable"]%>" />
var isEditable = $("#editable").attr("value");

Dies ist wahrscheinlich viel besser, da es das Skript intakt hält und es mir ermöglichen würde, es in eine externe .js-Datei zu verschieben. Aber etwas an dieser Lösung scheint auch nicht ideal zu sein. Oder bin es nur ich?

Kann jemand Lösungen und Best Practices für die Übergabe von Daten an Ihre Skripts empfehlen? Bin ich auf dem falschen Weg, wenn meine Skripte von vornherein stark auf die Ansichtsdaten meiner Controller angewiesen sind?

  • Wie wäre es, Daten aus dem Modell mit AJAX in eine Art Datenspeicher im Controller zu “ziehen”?

    – Janie

    28. Juli 2009 um 22:34 Uhr

  • Ich denke, AJAX wäre in der Art von Fällen, auf die ich mich beziehe, übertrieben … Meine Skripte müssen normalerweise nur ein paar Datenbits vom Controller / Modell kennen (Daten, die bereits bei der ersten Seitenausführung vorhanden sind). einen anderen Netzwerkrückruf an einen Controller auszugeben, scheint ein bisschen viel zu sein.

    – Kurt Schindler

    28. Juli 2009 um 22:45 Uhr

Benutzer-Avatar
Gabe Moothart

Ich übergebe manchmal Daten an meine Seiten, indem ich ein Konfigurationsobjekt über einen JSON-Serializer auf die Seite schreibe:

var pageConfig = <%= ServerConfig.ToJson() %>;

Wo Sie die ToJson-Methode selbst schreiben müssen. Dadurch bleibt der Seitenstatus übersichtlich, sodass es nur eine Stelle gibt, an der Sie Serverwerte einfügen. Von hier an ist alles reines Javascript. In Ihrem Beispiel könnten Sie dann Folgendes tun:

var isEditable = pageConfig.isEditable;

sogar in einer externen js-Datei, wenn pageConfig ist global. In diesem Fall sollten Sie es jedoch ordnungsgemäß benennen: MY_APP.pageConfig vielleicht.

  • Wirkt sich das nicht auf die Chachebarkeit aus? Zumindest kann jeder Seiten-GET eine andere Seite (andere Konfiguration) zurückgeben. Wenn Sie an Caches in Proxy-Servern denken, haben Sie jetzt für jeden Benutzer eine andere Version dieser Seite. Ist das überhaupt besorgniserregend?

    – John Saunders

    29. Juli 2009 um 0:45 Uhr

  • Dies ist eine faszinierende Option, aber ich bin mir nicht sicher, ob ich genau verstehe, wie Sie diese ServerConfig-Klasse implementieren. Tatsächlich kann jede Seite GET einen anderen Datensatz zurückgeben, müsste pageConfig also nicht letztendlich aus den ViewData jeder Seite festgelegt werden? Unabhängig davon werde ich Ihre anderen Vorschläge auf jeden Fall ausprobieren/überdenken (Json und eine globale js-Variable) – danke!

    – Kurt Schindler

    29. Juli 2009 um 13:20 Uhr

  • @Kurt – ja, ich denke, Sie müssten es aus den ViewData erstellen (vielleicht als anonymer Typ). Ich meinte nicht, dass Sie ViewData loswerden könnten, aber dass Sie die Anzahl der Stellen begrenzen könnten, an denen Sie Serverdaten auf der Seite einfügen.

    – Gabe Moothart

    29. Juli 2009 um 14:12 Uhr

Sie werden diese Informationen auf die eine oder andere Weise einspeisen. Und IMO, Ihr erstes Beispiel unterscheidet sich nicht wirklich vom zweiten.

Eine andere Lösung besteht darin, eine JS-Klasse (oder einen Prototyp?) zu haben, die ein Optionsobjekt akzeptiert. Obwohl es zugegebenermaßen nicht wirklich anders ist als die Beispiele, die Sie gegeben haben. Aber trotzdem, vielleicht möchtest du diesen Weg gehen.

$(function () {
    myClass.init({ isEditable: <%=ViewData["editable"]%>, 
        another: '<%=ViewData["another"]%>' });
});

Ich denke, @çağdaş macht einen guten Punkt, aber denken Sie daran, auch die Serverseite zu überprüfen. Wenn Sie ein Feld auf “schreibgeschützt” setzen, hindert nichts den Benutzer daran, dieses Flag zu ändern, ein schreibgeschütztes Feld zu ändern und zu senden.

Das gesamte Geschäft von Ajax ist zu Belastung Informationen asynchron. Wenn Sie die Aufgabe von Ajax erledigen (die Informationen laden und in einer Variablen speichern), wird ihm dadurch die Macht entzogen. Warum probieren Sie nicht JQuery aus und verwenden dessen Ajax- oder Get-Funktionen, um den Inhalt dynamisch zu laden. Es würde helfen, Ihre Seite schneller zu laden.

1206090cookie-checkBest Practices für die Übergabe von Daten von asp.net-mvc an Javascript

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy