Dlaczego zwracanie wygenerowanego HTML zamiast JSON jest złą praktyką? A może jest?

Zgadzam się głównie z opiniami tutaj przedstawionymi. Chciałem je tylko podsumować jako:

• To jest zła praktyka, aby wysłać HTML, jeśli kończy się parsowanie go po stronie klienta, aby wykonać kilka obliczeń na nim.

• Wysyłanie JSON jest złą praktyką, jeśli wszystko, co zrobisz, to włączenie go do drzewa DOM strony.

Cóż,

Jestem jedną z tych rzadkich osób, które lubią rozdzielać rzeczy w ten sposób: - Serwer jest odpowiedzialny za dostarczanie danych (model); - Klient jest odpowiedzialny za wyświetlanie (widok) i manipulowanie danymi (model);

Więc serwer powinien skupić się na dostarczaniu modelu (w tym przypadku JSON jest lepszy). W ten sposób uzyskasz elastyczne podejście. Jeśli chcesz zmienić widok twojego modelu, zachowaj serwer wysyłający te same dane i po prostu zmień klienta, komponenty javascript, które zmieniają te dane w widok. Wyobraź sobie, że masz serwer dostarczający dane do urządzeń mobilnych, a także aplikacji desktopowych.

Również takie podejście zwiększa produktywność, ponieważ serwer i Kod klienta mogą być budowane w tym samym czasie, nigdy nie tracąc ostrości, co dzieje się, gdy ciągle przełączasz się z js na PHP / JAVA / itp.

Ogólnie myślę, że większość ludzi woli robić jak najwięcej po stronie serwera, ponieważ nie opanowują js, więc starają się go unikać tak bardzo, jak możliwe.

Zasadniczo mam to samo zdanie co ci kolesie, którzy pracują nad Angular. Moim zdaniem taka jest przyszłość aplikacji internetowych.

Mam coś ciekawego, co mógłbym dodać. Opracowałem aplikację, która tylko raz załadowała pełny widok. Od tego momentu komunikował się z powrotem do serwera tylko za pomocą ajax. Trzeba było tylko załadować jedną stronę (mój powód jest tutaj nieistotny). Interesująca część polega na tym, że miałem specjalną potrzebę zwrócenia niektórych danych do obsługi w javascript i częściowego widoku do wyświetlenia. Mogłem podzielić to na dwa wezwania do dwóch oddzielnych działań metody, ale postanowiłem wybrać coś bardziej zabawnego.

Zobacz:

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

Co to jest RenderPartialViewToString ()? To jest ten mały samorodek chłodu tutaj:

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();
     }
}

Nie zrobiłem żadnych testów wydajności na tym, więc nie jestem pewien, czy wiąże się to więcej lub mniej narzutów niż wywołanie jednej metody akcji dla JsonResult i jednej dla ParticalViewResult, ale nadal myślałem, że to było całkiem fajne. Po prostu serializuje częściowy widok na ciąg znaków i wysyła go wraz z Json jako jeden z jego parametrów. Następnie używam JQuery, aby wziąć ten parametr i wsadzić go do odpowiedniego węzła DOM:)

Jeśli odpowiedź nie wymaga dalszego przetwarzania po stronie klienta, HTML jest moim zdaniem OK. Wysłanie JSON zmusi cię tylko do tego przetwarzania po stronie klienta.

Z drugiej strony, używam JSON, gdy nie chcę używać wszystkich danych odpowiedzi na raz. Na przykład, mam serię trzech połączonych selektów, gdzie wybrana wartość jednego określa, które wartości będą używane do wypełnienia drugiego, i tak dalej.

IMV, chodzi o oddzielenie danych od prezentacji danych, ale jestem z Pascalem, niekoniecznie wynika to z tego, że oddzielenie może być tylko przez granicę klient / serwer. Jeśli masz już tę separację (na serwerze) i po prostu chcesz pokazać coś klientowi, to czy odeślesz JSON i przetworzysz go na kliencie, czy po prostu odeślesz HTML, zależy całkowicie od twoich potrzeb. Powiedzieć, że" mylisz się " wysyłając HTML w ogólnym przypadku jest zbyt / align= "left" /

JSON jest bardzo wszechstronny i lekki format. Odkryłem jego piękno, gdy zacząłem używać go jako parsera szablonów po stronie klienta. Pozwól, że wyjaśnię, podczas gdy wcześniej używałem smarty i widoki po stronie serwera (generowanie wysokiego obciążenia serwera), teraz używam niektórych niestandardowych funkcji jquery i wszystkie dane są renderowane po stronie klienta, za pomocą przeglądarki klientów jako parser szablonów. oszczędza zasoby serwerów, a z drugiej strony przeglądarki codziennie poprawiają swoje silniki JS. Tak więc szybkość klienta parsowanie nie jest teraz ważnym problemem, co więcej, obiekty JSON są zwykle bardzo małe, więc nie zużywają zbyt wielu zasobów po stronie klienta. Wolę mieć powolną stronę dla niektórych użytkowników z powolną przeglądarką, niż powolną stronę dla wszystkich z powodu bardzo załadowanego serwera.

Z drugiej strony wysyłając czyste dane z serwera wyodrębniasz je z prezentacji, więc jeśli jutro chcesz je zmienić lub zintegrować swoje dane z inną usługą możesz to zrobić znacznie łatwiej.

Just my 2 centy.

Jeśli chcesz mieć czystego klienta odsprzęgniętego, co moim zdaniem jest najlepszą praktyką, to warto mieć 100% DOM stworzony przez javascript. Jeśli zbudujesz klienta opartego na MVC, który ma całą wiedzę, jak zbudować interfejs użytkownika, Twoi użytkownicy pobierają jeden plik javascript jeden raz i jest buforowany na kliencie. Wszystkie żądania po tym początkowym załadowaniu są oparte na Ajax i zwracają tylko dane. Takie podejście jest najczystsze, jakie znalazłem i zapewnia czystą, niezależną hermetyzację prezentacja.

Strona serwera skupia się wtedy na dostarczaniu danych.

Więc jutro, gdy produkt poprosi Cię o zmianę projektu strony całkowicie zmienisz tylko źródło JS, które tworzy DOM, ale prawdopodobnie ponownie wykorzystasz już istniejące procedury obsługi zdarzeń, a serwer jest nieświadomy, ponieważ w 100% odsprzęgnięty od prezentacji

W zależności od interfejsu użytkownika może być konieczne zaktualizowanie dwóch (lub więcej) różnych elementów w DOM. Jeśli Twoja odpowiedź jest w HTML, czy zamierzasz ją przeanalizować, aby dowiedzieć się, co idzie gdzie? Możesz też użyć JSON hash.

Można go nawet połączyć, zwracając dane JSON w / html:)

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

HTML posiada wiele zbędnych i nie wyświetlanych danych tj. znaczniki, arkusze stylów itp.. Tak więc rozmiar HTML w porównaniu do danych JSON będzie większy, co spowoduje więcej czasu pobierania i renderowania, a także spowoduje, że przeglądarka będzie zajęta renderowaniem nowych danych.

Wysyłanie json jest zazwyczaj wykonywane, gdy masz widżet javascript żądający informacji z serwera, takich jak lista, widok drzewa lub autouzupełnianie. To jest, kiedy chciałbym wysłać JSON, ponieważ są to dane, które będą przetwarzane i używane raw. Jednak jeśli po prostu pokaż HTML to jego o wiele mniej pracy, aby wygenerować go po stronie serwera i po prostu pokazać go w przeglądarce. Przeglądarki są zoptymalizowane do wstawiania HTML bezpośrednio do dom za pomocą innerHTML="", więc nie możesz się z tym pomylić.

Myślę, że to zależy od struktury projektu, po prostu bardziej seksowne jest używanie JSON niż HTML, ale pytanie brzmi, jak sobie z tym poradzić, aby można było go łatwo utrzymać.

Na przykład, powiedzmy, że mam stronę z listą, która wykorzystuje ten sam html / styl całej witryny, napiszę globalną funkcję do formatowania tych części HTML i wszystko, co muszę zrobić, to przekazać obiekt JSON do funkcji.

Odpowiedź Html jest wystarczająca w większości przypadków, chyba że trzeba wykonać jakieś obliczenia po stronie klienta.