Warum ist es eine schlechte Praxis, generiertes HTML statt JSON zurückzugeben? Oder ist es?

Ich stimme hauptsächlich den hier dargelegten Meinungen zu. Ich wollte sie nur zusammenfassen als:

• Es ist nicht empfehlenswert, HTML zu senden, wenn Sie es auf Clientseite analysieren, um Berechnungen durchzuführen.

• Es ist nicht empfehlenswert, JSON zu senden, wenn Sie es nur noch in den DOM-Baum der Seite integrieren möchten.

Gut,

Ich bin eine der seltenen Personen, die die Dinge auf diese Weise trennen möchte: - Der Server ist für die Bereitstellung von Daten (Modell) verantwortlich. ;

Der Server sollte sich daher auf die Bereitstellung des Modells konzentrieren (in diesem Fall ist JSON besser). Auf diese Weise erhalten Sie einen flexiblen Ansatz. Wenn Sie die Ansicht Ihres Modells ändern möchten, lassen Sie den Server dieselben Daten senden und ändern Sie einfach die Client-Javascript-Komponenten, die diese Daten in eine Ansicht umwandeln. Stellen Sie sich vor, Sie haben einen Server, der Daten sowohl auf mobilen Geräten als auch auf Desktop-Apps bereitstellt.

Außerdem erhöht dieser Ansatz die Produktivität, da Server- und Client-Code gleichzeitig erstellt werden können. Dabei bleibt der Fokus stets erhalten, wenn Sie ständig von js zu PHP/Java/usw. wechseln.

Im Allgemeinen denke ich, dass die meisten Leute es vorziehen, so viel wie möglich auf der Serverseite zu tun, da sie js nicht beherrschen, und versuchen, dies so weit wie möglich zu vermeiden.

Grundsätzlich habe ich die gleiche Meinung wie die Jungs, die an Angular arbeiten. Meiner Meinung nach ist dies die Zukunft der Web-Apps.

Ich habe etwas Interessantes, von dem ich dachte, ich könnte hinzufügen. Ich habe eine Anwendung entwickelt, die immer nur einmal die volle Ansicht geladen hat. Von diesem Zeitpunkt an kommunizierte es nur mit ajax zum Server zurück. Es musste immer nur eine Seite geladen werden (mein Grund ist hier unwichtig). Der interessante Teil kommt darin, dass ich ein besonderes Bedürfnis hatte, einige Daten zurückzugeben, die im Javascript bearbeitet werden sollen, und eine teilweise Ansicht anzuzeigen. Ich hätte das in zwei Aufrufe für zwei verschiedene Aktionsmethoden aufteilen können, aber ich entschied mich für etwas mehr Spaß.

Hör zu:

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

Was fragen Sie nach RenderPartialViewToString ()? Es ist dieses kleine Stück Coolness hier:

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

Ich habe diesbezüglich noch keine Leistungstests durchgeführt. Ich bin mir nicht sicher, ob dies mehr oder weniger Aufwand verursacht, als eine Action-Methode für JsonResult und eine für ParticalViewResult aufzurufen, aber ich fand es trotzdem ziemlich cool. Es serialisiert nur eine Teilansicht in eine Zeichenfolge und sendet sie zusammen mit dem Json als einen ihrer Parameter. Ich benutze dann JQuery, um diesen Parameter in den entsprechenden DOM-Knoten zu übernehmen :)

Lass mich wissen, was du von meinem Hybrid hältst!

Wenn die Antwort keine weitere clientseitige Verarbeitung erfordert, ist HTML meiner Meinung nach in Ordnung. Beim Senden von JSON müssen Sie nur diese clientseitige Verarbeitung durchführen.

Auf der anderen Seite verwende ich JSON, wenn ich nicht alle Antwortdaten gleichzeitig verwenden möchte. Zum Beispiel habe ich eine Reihe von drei verketteten Auswahlen, wobei der ausgewählte Wert von Eins bestimmt, welche Werte zum Füllen der zweiten verwendet werden sollen usw.

IMV, es geht nur darum, die Daten von der Darstellung der Daten zu trennen, aber ich bin bei Pascal, es folgt nicht zwangsläufig, dass diese Trennung nur über die Client/Server-Grenze erfolgen kann. Wenn Sie diese Trennung bereits haben (auf dem Server) und dem Client nur etwas anzeigen möchten, hängt es von Ihren Anforderungen ab, ob Sie JSON zurückschicken und auf dem Client nachbearbeiten oder nur HTML zurückschicken. Zu sagen, dass Sie "falsch" sind, um HTML im allgemeinen Fall zurückzusenden, ist eine zu große Aussage im IMV.

Wenn Sie einen sauberen, entkoppelten Client wünschen, was meiner Meinung nach die beste Vorgehensweise ist, ist es sinnvoll, 100% des durch JavaScript erstellten DOMs zu haben. Wenn Sie einen MVC-basierten Client mit allen Kenntnissen zum Erstellen der Benutzeroberfläche erstellen, laden Ihre Benutzer einmalig eine Javascript-Datei herunter, die auf dem Client zwischengespeichert wird. Alle Anforderungen nach diesem ersten Laden basieren auf Ajax und geben nur Daten zurück. Dieser Ansatz ist der sauberste, den ich gefunden habe, und sorgt für eine saubere unabhängige Kapselung der Präsentation.

Die Serverseite konzentriert sich dann auf die Bereitstellung von Daten.

Wenn also morgen das Produkt Sie dazu auffordert, das Design einer Seite vollständig zu ändern, ändern Sie lediglich den Quell-JS, der das DOM erstellt. Wahrscheinlich werden jedoch bereits vorhandene Event-Handler wiederverwendet, und der Server ist nicht zu 100% von der Präsentation entkoppelt

JSON ist ein sehr vielseitiges und leichtes Format. Ich habe seine Schönheit entdeckt, als ich angefangen habe, es als clientseitige Vorlagen-Parserdaten zu verwenden. Lassen Sie mich erklären, dass ich, bevor ich Smarty und Ansichten auf Serverseite verwendet habe (hohe Serverlast erzeugt), jetzt einige benutzerdefinierte Jquery-Funktionen verwende und alle Daten auf Clientseite gerendert werden, wobei der Clientbrowser als Vorlagenparser verwendet wird. Es spart Serverressourcen und auf der anderen Seite verbessern Browser ihre JS-Engines täglich. Daher ist die Geschwindigkeit des Client-Parsings derzeit kein wichtiges Thema. Außerdem sind JSON-Objekte normalerweise sehr klein, sodass sie nicht viele Ressourcen auf der Clientseite beanspruchen. Ich ziehe es vor, eine langsame Website für einige Benutzer mit einem langsamen Browser zu haben, als eine langsame Website für alle, da der Server stark belastet ist.

Auf der anderen Seite abstrahieren Sie reine Daten vom Server, sodass Sie sie von der Präsentation abstrahieren. Wenn Sie also morgen Daten ändern oder Ihre Daten in einen anderen Dienst integrieren möchten, ist dies viel einfacher.

Nur meine 2 Cent.

Abhängig von Ihrer Benutzeroberfläche müssen Sie möglicherweise zwei (oder mehr) verschiedene Elemente in Ihrem DOM aktualisieren. Wenn Ihre Antwort in HTML ist, werden Sie das analysieren, um herauszufinden, was wohin geht? Oder Sie können einfach einen JSON-Hash verwenden.

Sie können es sogar kombinieren und JSON mit HTML-Daten zurückgeben :)

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

HTML hat viele redundante und nicht angezeigte Daten, d. H. Tags, Stylesheets usw. Daher ist die HTML-Größe im Vergleich zu JSON-Daten größer, was zu mehr Download- und Renderzeit führt und den Browser mit dem Rendern der neuen Daten beschäftigt.

Das Senden von Json erfolgt in der Regel, wenn Sie ein Javascript-Widget haben, das Informationen vom Server anfordert, z. B. eine Liste, eine Baumansicht oder eine automatische Vervollständigung. Dies ist, wenn ich JSON senden würde, da es sich um Daten handelt, die analysiert und als Rohdaten verwendet werden. Wenn Sie jedoch nur HTML anzeigen, ist es viel weniger Arbeit, es serverseitig zu generieren und es einfach im Browser anzuzeigen. Browser sind für das direkte Einfügen von HTML in den Dom mit innerHTML = "" optimiert, damit Sie nichts falsch machen können.

Kommt auf die Umstände an.

Manchmal ist es wichtig, auf JSON zu verzichten. Wenn unsere Programmierer beispielsweise Probleme beim Programmieren in js haben.

Meine Erfahrung sagt mir: Verwenden Sie den Ajax-Dienst besser als Inline-JSON.

Früher oder später wird das js zum Problem

In den meisten Fällen reicht die HTML-Antwort aus, es sei denn, Sie müssen eine Berechnung auf der Clientseite durchführen.

Ich denke, es hängt von der Struktur des Designs ab. Es ist nur sexy, JSON zu verwenden als HTML, aber die Frage ist, wie man damit umgehen würde, so dass es leicht zu warten ist.

Angenommen, ich habe die Auflistungsseite, die den gleichen HTML-Stil/Stil der gesamten Site verwendet. Ich würde die globale Funktion zum Formatieren dieser HTML-Teile schreiben. Alles, was ich tun muss, ist das JSON-Objekt in die Funktion zu übergeben.