为什么返回生成的HTML而不是JSON是一个坏习惯?还是这样?

实际上,我有点两面性:

• 当我在javascript方面需要的是 数据 我用JSON
• 当我在javascript方面需要的是 演示 在这上面我不做任何计算,我通常使用HTML

使用HTML的主要优点是,当您想用Ajax请求返回的内容替换整个页面时:

• 在JS中重建页面的一部分非常困难
• 您可能在服务器端已经有了一些模板化引擎,它首先用于生成页面…为什么不重用它?

我通常不考虑事物的“性能”方面,至少在服务器上是这样:

• 在服务器上,生成一部分HTML或一些JSON可能不会有太大的区别。
• 关于通过网络传输的内容的大小:好吧,您可能不使用数百kb的数据/html…在传输的任何内容上使用gzip将是最大的区别 (不在HTML和JSON之间选择)
• 不过,可以考虑的一点是,在客户端上重新创建HTML需要哪些资源 (或DOM结构) 从JSON数据…将其与将一部分HTML推入页面进行比较;-)

最后,有一件事很重要:

• 开发一个以JSON形式发送数据的新系统需要多长时间+编写将其作为HTML注入页面所需的JS代码?
• 只返回HTML需要多长时间?如果您可以重新使用一些已经存在的服务器端代码,需要多长时间?

回答另一个问题:如果需要更新页面的多个部分,仍然有一个解决方案/方法,即将所有这些部分发送到一个大字符串中,该字符串将几个HTML部分分组,并在JS中提取相关部分。

例如,可以返回如下字符串:

<!-- 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子字符串方法可以做到这一点;-)

我主要同意这里的意见。我只是想把它们概括为:

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

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

好,

我是少数喜欢用这种方式分开事物的人之一: -服务器负责传递数据(模型); -客户机负责显示(查看)和操作数据(模型);

因此,服务器应该专注于交付模型(在本例中,JSON更好)。 这样你就有了一个灵活的方法。如果您想更改模型的视图,可以让服务器发送相同的数据,只需更改将数据更改为视图的客户机、JavaScript组件。想象一下,您有一台服务器,它向移动设备和桌面应用程序提供数据。

此外,这种方法提高了生产率,因为服务器和客户端代码可以同时构建,永远不会丢失焦点,这是当您从JS切换到PHP/Java/等时发生的事情。

一般来说,我认为大多数人喜欢在服务器端尽可能多地做,因为他们不掌握JS,所以他们尽量避免使用它。

基本上,我和那些研究角度的人有相同的观点。在我看来,这就是网络应用的未来。

我有一些有趣的东西,我想我可以补充一下。我开发了一个只加载一次完整视图的应用程序。从那时起,它只通过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调用一个操作方法和为particalView结果调用一个操作方法带来更多或更少的开销,但我仍然认为这很酷。它只是将一个局部视图序列化为一个字符串,并将它与JSON一起作为它的参数之一发送。然后,我使用jquery获取该参数并将其放入适当的dom节点中:)

让我知道你对我的混合动力车的看法!

如果响应不需要进一步的客户端处理,我认为HTML是可以的。发送JSON只会强制您进行客户端处理。

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

IMV,这一切都是为了将数据从数据的表示中分离出来,但是我和Pascal在一起,并不一定意味着分离只能跨越客户机/服务器边界。如果您已经有了这种分离(在服务器上),并且只想向客户机显示一些东西,那么您是发送回JSON并在客户机上对其进行后处理,还是只发送回HTML,完全取决于您的需要。在一般情况下,说你“错了”发送回HTML,这太笼统了一个声明IMV。

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

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

只有我的2美分。

如果您想要一个干净的分离客户机,在我看来这是最佳实践,那么让100%的DOM由JavaScript创建是有意义的。如果您构建的是一个基于MVC的客户机,它具有构建UI的全部诀窍,那么您的用户可以一次下载一个javascript文件,并将其缓存在客户机上。初始加载之后的所有请求都是基于Ajax的,并且只返回数据。这种方法是我所发现的最干净的方法,并且提供了一个干净的、独立的表示封装。

然后,服务器端只关注传递数据。

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

根据您的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>' }

HTML有许多冗余和未显示的数据,如标签、样式表等。 因此,与JSON数据相比,HTML的大小将更大,从而导致更多的下载和呈现时间,同时也会导致浏览器忙于呈现新数据。

发送JSON通常是在有一个JavaScript小部件从服务器请求信息时完成的,例如列表、树视图或自动完成。这是我发送JSON的时候,因为它是将被解析和原始使用的数据。但是,如果您只想显示HTML,那么在服务器端生成它并在浏览器上显示它的工作就要少得多。浏览器经过优化,可以将HTML直接插入到带有innerhtml的DOM中,因此您不会出错。

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

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

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

视情况而定。

有时避免JSON是必要的。 例如,当我们的程序员在JS中编程遇到问题时。

我的经验告诉我:最好使用Ajax服务,而不是内联JSON。

JS迟早会成为一个问题