为什么返回生成的HTML而不是JSON是一个坏的做法?真的是这样吗?

实际上，我在这两方面都有点偏袒:

• 当我在javascript端需要数据时，我使用JSON
• 当我在javascript方面需要的是演讲，我不会做任何计算，我通常使用HTML

使用HTML的主要优势是当你想用Ajax请求返回的内容替换页面的完整部分时:

• 用JS重新构建页面的一部分(相当)困难
• 您可能已经在服务器端有了一些模板引擎，用于首先生成页面……为什么不重复使用呢?

我通常不考虑“性能”方面的事情，至少在服务器上:

• 在服务器上，生成一部分HTML或一些JSON可能不会产生太大的差异
• 关于通过网络的东西的大小:好吧，你可能不会使用数百KB的数据/html……在你要传输的任何东西上使用gzip将会产生最大的不同(不能在HTML和JSON之间选择)
• 不过，有一件事需要考虑，你需要在客户端上使用什么资源来从JSON数据重新创建HTML (或DOM结构)…将其与将部分HTML推入页面进行比较;-)

最后，有一件事肯定很重要:

• 开发一个新系统需要多长时间，该系统将以JSON +代码的形式发送数据，并将其作为HTML注入到页面中?
• 返回HTML需要多长时间?重用一些已经存在的服务器端代码需要多长时间?

例如，你可以返回一些字符串，看起来像这样:

<!-- 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 -->

这看起来不太好，但它肯定是有用的(我用过很多次，大多数时候HTML数据太大，无法封装成JSON):你正在为页面中需要表示的部分发送HTML，你正在为你需要数据的情况发送JSON…

．.． 要提取这些，JS的substring方法将会做的技巧，我想;-)

如果响应不需要进一步的客户端处理，在我看来，HTML是可以的。发送JSON只会迫使您执行客户端处理。

另一方面，当我不想一次使用所有响应数据时，我会使用JSON。例如，我有一系列三个链式选择，其中一个的选定值决定哪些值将用于填充第二个，依此类推。

根据您的UI，您可能需要更新DOM中的两个(或多个)不同元素。如果你的响应是HTML格式的，你会解析它来确定内容在哪里吗?或者你也可以使用JSON散列。

你甚至可以结合它，返回一个JSON w/ html数据:)

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

IMV，就是把数据从数据的表示中分离出来，但是我支持Pascal，并不是说这种分离只能跨越客户端/服务器的边界。如果你已经(在服务器上)有了这种分离，只是想向客户端显示一些东西，那么你是在客户端返回JSON并对其进行后期处理，还是仅仅返回HTML，这完全取决于你的需要。在一般情况下，说你“错误”地发送回HTML只是一个太笼统的IMV声明。

我主要同意这里的观点。我想总结一下:

• 如果您最终要在客户端解析HTML以对其进行一些计算，那么发送HTML是一种糟糕的做法。

• 如果您最终所做的只是将JSON合并到页面的DOM树中，那么发送JSON是一种糟糕的做法。

发送json通常是在javascript小部件从服务器请求信息时完成的，比如列表、树视图或自动补全。这是当我将发送JSON，因为它是数据，将被解析和使用原始。然而，如果你只是要显示HTML，那么在服务器端生成它并在浏览器上显示它就会少很多工作。浏览器在使用innerHTML = ""直接将HTML插入dom时进行了优化，所以这样做不会出错。

JSON是非常通用和轻量级的格式。当我开始使用它作为客户端模板解析器数据时，我发现了它的美妙之处。让我解释一下，之前我在服务器端使用smarty和视图(产生高服务器负载)，现在我使用一些自定义jquery函数和所有的数据在客户端渲染，使用客户端浏览器作为模板解析器。它节省了服务器资源，另一方面浏览器每天都在改进他们的JS引擎。所以客户端解析的速度现在不是一个重要的问题，更重要的是，JSON对象通常非常小，所以它们不会消耗大量的客户端资源。我更喜欢有一个缓慢的网站，为一些用户缓慢的浏览器，而不是缓慢的网站为每个人，因为非常负载的服务器。

另一方面，从服务器发送纯数据，你可以从表示中抽象它，所以如果明天你想改变它或将你的数据集成到另一个服务中，你可以更容易地做到这一点。

这只是我的个人意见。

我认为这取决于设计的结构，使用JSON比使用HTML更吸引人，但问题是如何处理它，使其易于维护。

例如，假设我有一个使用整个网站相同html/风格的列表页面，我将编写全局函数来格式化html的这些部分，我所要做的就是将JSON对象传递到函数中。

我有一些有趣的东西，我想我可以添加。我开发了一个应用程序，只加载一个完整的视图一次。从那时起，它只使用ajax与服务器通信。它只需要加载一个页面(我这样做的原因在这里不重要)。有趣的部分是，我有一个特殊的需要，返回一些数据要在javascript操作和部分视图显示。我本可以把它分成两个调用，分别调用两个单独的动作方法，但我决定用一些更有趣的东西。

看看吧:

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

你可能会问RenderPartialViewToString()是什么?就是这个小块的酷:

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

我还没有做任何性能测试，所以我不确定它是否招致任何更多或更少的开销调用一个动作方法为JsonResult和一个为ParticalViewResult，但我仍然认为这是相当酷的。它只是将一个局部视图序列化为一个字符串，并将它与Json作为参数之一一起发送。然后，我使用JQuery来获取该参数，并将其打到适当的DOM节点:)

告诉我你对我的混血儿有什么看法!

好吧,

此外，这种方法提高了工作效率，因为服务器和客户端代码可以同时构建，永远不会失去从js切换到PHP / JAVA / etc时所发生的重点。

一般来说，我认为大多数人更喜欢在服务器端做尽可能多的事情，因为他们不精通js，所以他们尽量避免它。

基本上，我和那些致力于Angular的人有着相同的观点。在我看来，这就是网络应用的未来。

Html响应在大多数情况下是足够的，除非你必须在客户端执行一些计算。

如果你想要一个干净的解耦客户端(在我看来这是最佳实践)，那么100%的DOM由javascript创建是有意义的。如果你构建了一个基于MVC的客户端，它拥有如何构建UI的所有知识，那么你的用户一次下载一个javascript文件，它就会缓存在客户端上。初始加载之后的所有请求都是基于Ajax的，并且只返回数据。这种方法是我发现的最干净的方法，它提供了一个干净独立的表示封装。

然后，服务器端只专注于交付数据。

所以，明天当产品要求你完全改变一个页面的设计时，你所改变的只是创建DOM的源JS，但可能会重用你已经存在的事件处理程序，而服务器是无关的，因为它100%与表示分离

这取决于具体情况。

我的经验告诉我:使用ajax服务比使用内联JSON更好。

迟早js会成为一个问题