首页 文章

为什么返回生成的HTML而不是JSON是一种不好的做法?或者是吗?

提问于
浏览
287

使用JQuery或任何其他类似框架从您的自定义URL / Web服务加载HTML内容非常容易 . 我已经多次使用这种方法,直到现在,发现性能令人满意 .

但是所有的书籍,所有专家都试图让我使用JSON而不是生成HTML . 它是如何比HTML更优越的?

Is it very much faster? Does it have a very much lesser load on the server?

另一方面,我有一些使用生成的HTML的原因 .

  • 这是简单的标记,通常与JSON一样紧凑或实际上更紧凑 .

  • 它's less error prone cause all you'重新获得是标记,没有代码 .

  • 在大多数情况下编程会更快,因为您不必为客户端单独编写代码 .

你是哪一方,为什么?

14 回答

  • 241

    我有一些有趣的东西,我想我可能会添加 . 我开发了一个只能一次加载完整视图的应用程序 . 从那时起,它仅通过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节点:)

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

  • 1

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

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

  • 7

    IMV,它都是关于将数据与数据表示分离,但是我使用的是Pascal,它不一定表明分离只能跨越客户端/服务器边界 . 如果您已经(在服务器上)有这种分离并且只想向客户端显示某些内容,无论是发送回JSON并在客户端上对其进行后处理,还是只发送回HTML,完全取决于您的需求 . 要说你在一般情况下发回HTML是“错误的”,这只是IMV的一个声明 .

  • 6

    取决于具体情况 .

    有时候避免使用JSON是必不可少的 . 例如,当我们的程序员在js中编程时遇到问题 .

    我的经验告诉我:更好地使用ajax服务而不是内联JSON .

    js迟早会成为一个问题

  • 26

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

  • 4

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

    除非您必须在客户端执行某些计算,否则在大多数情况下Html响应就足够了 .

  • 2

    我主要同意这里所说的意见 . 我只是想总结一下:

    • 如果您最终解析客户端以对其进行一些计算,则发送HTML是不好的做法 .

    • 如果您最终要做的就是将它合并到页面的DOM树中,那么发送JSON是不好的做法 .

  • 6

    如果你想要一个干净的解耦客户端,在我看来这是最佳实践,那么有100%的jQuery创建的DOM是有意义的 . 如果您构建了一个基于MVC的客户端,该客户端具有所有知道如何构建UI的权限,那么您的用户一次下载一个javascript文件并将其缓存在客户端上 . 初始加载后的所有请求都是基于Ajax的,只返回数据 . 这种方法是我发现的最干净的方法,并提供了一个干净的独立封装的演示文稿 .

    然后,服务器端专注于提供数据 .

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

  • 9

    我有点双方,实际上:

    • 当我在javascript端需要 data 时,我使用JSON

    • 当我在javascript端需要的是 presentation 时我不会做任何计算,我通常使用HTML

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

    • 在JS中重建一部分页面非常困难

    • 你可能已经在服务器端有一些模板引擎,它首先用于生成页面...为什么不重用它?

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

    • 在服务器上,生成一部分HTML或一些JSON可能不会产生太大的影响

    • 关于通过网络的东西的大小:嗯,你可能不会做出最大的改变(不是在HTML和JSON之间选择)

    • 但是,可以考虑的一件事是,客户端需要从JSON数据重新创建HTML(或DOM结构)的资源...将其与将部分HTML推送到页面中进行比较;-)

    最后,有一点肯定很重要:

    • 开发一个新系统需要多长时间才能将数据作为JSON代码发送到JS所需的将其作为HTML注入页面?

    • 返回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子串方法会起作用;-)

  • 108

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

    另一方面,从服务器发送纯数据,您将其从演示文稿中抽象出来,如果明天您想要更改它或将您的数据集成到另一个服务中,您可以更轻松地完成它 .

    只需2美分 .

  • 0

    好,

    我是那些喜欢以这种方式分离事物的少数人之一: - 服务器负责提供数据(模型); - 客户负责显示(查看)和操纵数据(模型);

    因此,服务器应该专注于交付模型(在这种情况下,JSON更好) . 这样您就可以获得灵活的方法 . 如果要更改模型的视图,可以让服务器发送相同的数据,只需更改将数据更改为视图的客户端javascript组件即可 . 想象一下,您有一台服务器向移动设备和桌面应用程序提供数据 .

    此外,这种方法提高了工作效率,因为服务器和客户端代码可以同时构建,永远不会失去焦点,这是当你从js切换到PHP / JAVA /等时发生的事情 .

    一般来说,我认为大多数人更喜欢在服务器端尽可能多地做,因为他们不掌握js,所以他们试图尽可能地避免它 .

    基本上,我和那些正在研究Angular的人有同样的看法 . 在我看来,这是Web应用程序的未来 .

  • 8

    HTML有许多冗余且未显示的数据,即标签,样式表等 . 因此,与JSON数据相比,HTML大小会更大,导致更多的下载和渲染时间,这也会导致浏览器忙于呈现新数据 .

  • 0

    我认为这取决于设计的结构,使用JSON比使用HTML更性感,但问题是如何处理它以便可以轻松维护 .

    例如,假设我有列表页面利用整个网站的相同html /样式,我会编写全局函数来格式化HTML的这些部分,我所要做的就是将JSON对象传递给函数 .

相关问题