为什么返回生成的HTML而不是JSON是不好的做法？ 还是呢？
使用JQuery或任何其他类似框架从您的自定义URL / Web服务加载HTML内容是相当容易的。 我已经多次使用这种方法，直到现在，发现性能令人满意。
但所有的书籍，所有的专家都试图让我使用JSON而不是生成的HTML。 它比HTML好得多吗？
速度非常快吗？
它在服务器上的负载是否非常低？
另一方面，我有一些使用生成的HTML的原因。
- 这是简单的标记，并且通常与JSON一样紧凑或者实际上更紧凑。
- 这是不太容易出错，因为你得到的是标记，没有代码。
- 在大多数情况下编程会更快，因为您不必为客户端单独编写代码。
你在哪边？为什么？
实际上，我有点双方
- 当我需要在JavaScript端数据 ，我使用JSON
- 当我需要在JavaScript端的演示文稿 ，我不会做任何计算，我通常使用HTML
使用HTML的主要优势在于，当您要将页面的整个部分replace为来自Ajax请求的内容时：
- 在JS中重build页面的一部分是相当困难的
- 您可能已经在服务器端有一些模板引擎，用于生成页面，为什么不重用？
我至less在服务器上一般不考虑事物的“性能”方面：
- 在服务器上，生成一部分HTML或一些JSON不会造成很大的差别
- 关于通过networking的东西的大小：好吧，你可能不使用数百KB的数据/ HTML …使用gzip无论你正在传递什么是最大的区别（不selectHTML和JSON）
- 但是，可以考虑的一件事就是客户端需要从JSON数据中重新创buildHTML （或DOM结构）所需的资源，比如将一部分HTML推入页面; – ）
最后，最重要的一点是：
- 需要多长时间才能开发一个新的系统，以JSON +代码的forms发送数据，JS需要将它作为HTML注入到页面中？
- 多久才能返回HTML？ 如果你可以重复使用已经存在的一些服务器端代码多久？
并回答另一个答案：如果您需要更新页面的多个部分，仍然有解决scheme/黑客发送所有这些部分内的一个大string组成几个HTML部分，并提取有关部分在JS中。
例如，你可以返回一些看起来像这样的string：
<!-- 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子string方法将做的伎俩，我想;-)
我主要同意这里所说的意见。 我只想把它们总结为：
-
如果你最终parsing客户端来做一些计算，发送HTML是不好的做法。
-
发送JSON是一个不好的做法，如果你最终要做的就是把它合并到页面的DOM树中。
好，
我是那些喜欢用这种方式分离事物的罕见人士之一： – 服务器负责提供数据（模型）; – 客户负责显示（查看）和操纵数据（模型）;
所以，服务器应该专注于交付模型（在这种情况下，JSON更好）。 这样你就可以得到一个灵活的方法。 如果你想改变你的模型的视图，你让服务器发送相同的数据，只是改变客户端，JavaScript组件，将数据更改为一个视图。 想象一下，你有一台服务器将数据传送到移动设备以及桌面应用程序。
此外，这种方法提高了生产力，因为服务器和客户端代码可以同时构build，而不会失去焦点，这是从js切换到PHP / JAVA等时会发生的。
一般来说，我想大多数人喜欢在服务器端尽可能多的做，因为他们不掌握js，所以尽量避免。
基本上，我和那些在Angular上工作的人有相同的意见。 在我看来，这是networking应用程序的未来。
我想我可能会添加一些有趣的东西。 我开发了一个应用程序，只有一次加载完整的视图。 从这一点开始，它只能通过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(); } }
我还没有做过任何性能testing，所以我不确定是否会比调用JsonResult的一个操作方法和ParticalViewResult的一个方法花费更多或更less的开销，但我仍然认为它非常酷。 它只是将部分视图序列化为一个string，并将其作为参数之一与Json一起发送。 然后，我使用JQuery来接受这个参数，并把它放到它合适的DOM节点:)
让我知道你对我的混合动力的想法！
如果响应不需要进一步的客户端处理，我认为HTML是可以的。 发送JSON只会强制您执行客户端处理。
另一方面，当我不想一次使用所有的响应数据时，我使用JSON。 例如，我有一系列的三个链式select，其中一个select的值决定哪些值将用于填充第二个，依此类推。
IMV就是将数据从数据表示中分离出来，但是我使用的是Pascal，它并不一定表示这种分离只能跨越客户/服务器边界。 如果你已经（在服务器上）已经有了这种分离，只是想向客户端展示一些东西，不pipe你发回JSON并在客户端进行后处理，还是只发回HTML，都完全取决于你的需求。 要说在一般情况下发送HTML是“错误的”，这只是一个陈述IMV。
JSON是非常通用和轻量级的格式。 当我开始使用它作为客户端模板parsing器数据时，我发现了它的美。 让我解释一下，虽然之前我在服务器端使用smarty和视图（生成高服务器负载），现在我使用一些自定义的jquery函数和所有的数据呈现在客户端，使用客户端浏览器作为模板分析器。 它节省了服务器资源，另一方面浏览器每天都在改进他们的JS引擎。 所以客户端parsing的速度现在不是一个重要的问题，更重要的是，JSON对象通常很小，所以不会消耗大量的客户端资源。 对于一些使用慢速浏览器的用户而言，我更喜欢使用缓慢的网站，而不是每个人的网站速度都很慢，因为服务器负载很重。
另一方面，从服务器发送纯数据，您从演示文稿中抽象出来，所以如果明天要更改它，或者将数据集成到另一个服务中，则可以更容易。
只是我2美分。
如果你想要一个干净的解耦客户端，在我看来这是最好的实践，那么通过javascript创build100％的DOM是有道理的。 如果您构build了一个基于MVC的客户端，并且知道如何构buildUI，那么您的用户只需下载一个JavaScript文件，并将其caching到客户端。 初始加载之后的所有请求都是基于Ajax的，只返回数据。 这种方法是我find的最干净的，并提供了一个干净的独立封装的演示文稿。
服务器端则专注于提供数据。
所以明天当产品要求你完全改变一个页面的devise时，所有你改变的就是创buildDOM的源代码JS，但是可能会重用已经存在的事件处理程序，而服务器是不经意的，因为它与演示100％分离
根据您的UI，您可能需要更新DOM中的两个（或更多）不同的元素。 如果你的回复是用HTML格式的，你打算parsing一下，弄清楚什么地方在哪里？ 或者你可以使用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，因为它是将被parsing和使用原始数据。 但是，如果你只是要显示的HTML，那么它生成服务器端的很less的工作，只是显示在浏览器上。 浏览器针对直接插入到innerHTML =“”dom中的HTML进行了优化，所以你不能错误的。
我认为这取决于devise的结构，使用JSON比HTML更性感，但问题是如何处理它，以便于维护。
例如，假设我有使用整个站点的html / style的列表页面，我将编写全局函数来格式化HTML的所有部分，我所要做的就是将JSON对象传递给函数。
除非你必须在客户端执行一些计算，否则在大多数情况下Html响应已经足够了。
