Pourquoi est-ce une mauvaise pratique de retourner le code HTML généré au lieu de JSON? Ou est-ce?

Question

Il est assez facile de charger du contenu HTML à partir de votre Url personnalisées/services Web à l'aide de JQuery ou de tout autre cadre. J'ai utilisé cette méthode plusieurs fois et jusqu'à maintenant, et a trouvé la performance satisfaisante.

Mais tous les livres, tous les experts sont d'essayer de me faire utiliser JSON au lieu de HTML généré. Comment est-il beaucoup plus supérieur que le HTML?

Est-il très vite?
A-t-il beaucoup moins de charge sur le serveur?

De l'autre côté j'ai quelques raisons pour l'utilisation de code HTML généré.

1. C'est simple balisage, et souvent tout aussi compact ou en fait, plus compact que le format JSON.
2. C'est moins sujette aux erreurs cause tout ce que vous obtenez est de balisage, et aucun code.
3. Il sera plus rapide à programmer dans la plupart des cas, la cause de ne pas avoir à écrire du code séparément pour le client final.

De quel côté êtes-vous et pourquoi?

Answer 1

Je suis un peu sur les deux côtés, en fait :

• Lors de ce dont j'ai besoin sur le javascript côté est de données, j'utilise JSON
• Lors de ce dont j'ai besoin sur le javascript côté est de la présentation sur laquelle je ne vais pas faire le calcul, en général, je utiliser de l'HTML

Le principal avantage de l'utilisation de HTML, c'est quand vous voulez remplacer une portion complète de votre page avec ce qui vient de revenir de la requête Ajax :

• Re-construction d'une partie de la page en JS est (très) dur
• Vous avez déjà probablement certains moteur de template sur le côté serveur, qui a été utilisé pour générer la page, en premier lieu... Pourquoi ne pas le réutiliser ?

En général je n'ai pas vraiment prendre en compte la "performance" du côté des choses, au moins sur le serveur :

• Sur le serveur, générant une portion de HTML ou de certains JSON ne serez pas probablement faire beaucoup de différence
• Au sujet de la taille de ce qui se passe à travers le réseau : eh bien, vous n'avez probablement pas utiliser des centaines de KO de données/html... à l'Aide de gzip sur tout ce que vous transférez est ce qui va faire la plus grande différence (pas de choisir entre HTML et JSON)
• Une chose qui pourrait être pris en considération, cependant, est que les ressources dont vous aurez besoin sur le client afin de recréer le HTML (DOM structure de données JSON... de la comparer à pousser une partie de HTML dans la page ;-)

Enfin, une chose que définitivement les questions :

• Combien de temps ça va vous prendre pour développer un nouveau système qui permettra d'envoyer des données en JSON + code de la JS injecter comme du HTML dans la page ?
• Combien de temps cela prend-il pour juste retour HTML ? Et combien de temps si vous pouvez réutiliser certains de votre code côté serveur ?

Et pour répondre à une autre réponse : si vous avez besoin de mettre à jour plus d'une partie de la page, il y a toujours la solution de hack de l'envoi de toutes les pièces à l'intérieur d'une grande chaîne qui regroupe plusieurs HTML parties, et d'en extraire les éléments pertinents en JS.

Par exemple, vous pourriez retourner une chaîne de caractères qui ressemble à ceci :

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

Qui n'a pas l'air vraiment bon, mais il est certainement utile (je l'ai utilisé tout à fait une couple de fois, surtout quand le HTML, les données étaient trop gros pour être encapsulé dans JSON) : vous envoyez HTML pour les parties de la page qui ont besoin de présentation, et vous envoyez JSON pour la situation que vous avez besoin de données...

... Et pour extraire celles-ci, la JS sous-chaîne de la méthode fera l'affaire, je suppose ;-)

Answer 2

Je suis principalement d'accord avec les opinions exprimées ici. Je voulais juste les résumer comme:

• C'est une mauvaise pratique d'envoyer du code HTML si vous finissez par l'analyser côté client pour faire des calculs dessus.

• C'est une mauvaise habitude d'envoyer JSON si tout ce que vous finissez par faire est de l'incorporer dans l'arbre DOM de la page.

Answer 3

Eh bien,

Je suis l'une de ces rares personnes qui aime à séparer les choses de cette façon: - Le serveur est responsable de la fourniture de données (modèle); - Le client est responsable de la montre (vue) et la manipulation de données (modèle);

Donc, le serveur devrait se concentrer sur la prestation de modèle (dans ce cas, JSON est mieux). De cette façon, vous obtenez une approche flexible. Si vous voulez changer la vue de votre modèle, vous gardez le serveur envoi les mêmes données, il suffit de changer le client, des composants javascript, qui permet de changer les données dans une vue. Imaginez, vous avez un serveur de fourniture de données pour les appareils mobiles ainsi que des applications de bureau.

Aussi, cette approche augmente la productivité, étant donné que le serveur et le code client peut être construit en même temps, sans jamais perdre le focus qui est ce qui se passe quand vous gardez de commutation de js, PHP / JAVA / etc.

En général, je pense que la plupart des personnes préfèrent le faire autant que possible sur le côté serveur, parce qu'ils ne maîtrisent pas le js, donc ils essaient de l'éviter autant que possible.

En gros, j'ai le même avis que ceux qui travaillent sur Angulaire. À mon avis, c'est l'avenir du web apps.

Answer 4

J'ai quelque chose d'intéressant, j'ai pensé que je pourrais ajouter. J'ai développé une application qui n'a jamais chargé d'une vue une seule fois. À partir de ce moment, il a communiqué sur le serveur avec l'ajax. Il n'a jamais besoin de charger une page (ma raison pour cela est sans importance ici). La partie la plus intéressante vient que j'avais un besoin particulier de retour de certaines données pour être exploité dans le javascript ET une vue partielle d'être affiché. Je pourrais avoir divisé en deux appels pour les deux méthodes d'action mais j'ai décidé d'aller avec quelque chose d'un peu plus de fun.

Check it out:

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

Qu'est-ce que RenderPartialViewToString (), vous pourriez demander? C'est cette petite pépite de fraîcheur, ici:

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

Je n'ai pas fait de tests de performance sur ce que je ne suis pas sûr s'il encourt l'une plus ou moins généraux que l'appel d'une méthode d'action pour l'JsonResult et un pour le ParticalViewResult, mais j'ai toujours pensé que c'était assez cool. Il vient de sérialise une vue partielle en une chaîne de caractères et l'envoie avec le Json comme l'une de ses paramètres. J'ai ensuite utiliser JQuery pour prendre ce paramètre et collez-le dans il est approprié nœud DOM :)

Laissez-moi savoir ce que vous pensez de mon hybride!

Answer 5

Si la réponse n'a pas besoin d'un traitement supplémentaire côté client, HTML est OK à mon avis. L'envoi de JSON ne vous obligera à effectuer ce traitement côté client.

D'un autre côté, j'utilise JSON quand je ne veux pas utiliser toutes les données de réponse à la fois. Par exemple, j'ai une série de trois sélections chaînées, où la valeur sélectionnée de un détermine les valeurs qui vont être utilisées pour remplir la seconde, et ainsi de suite.