JSON is very versatil and lightweight format. I have discovered its beauty when I have started to use it as a client side template parser data. Let me explain, while before I was using smarty and views on server side (generating high server load), now I use some custom jquery functions and all the data is rendered on client side, using clients browser as template parser. it saves server resourses and on another hand browsers improve their JS engines every day. So the speed of client parsing is not an important issue right now, even more, JSON objects are ususally very small so they don't consume a lot of client side resourses. I prefer to have a slow website for some users with slow browser rather than slow site for everyone because of very loaded server.

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

这只是我的个人意见。

如果你想要一个干净的解耦客户端(在我看来这是最佳实践)，那么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>' }

I have something interesting I thought I might add. I developed an application that only ever loaded a full view one time. From that point forward it communicated back to the server with ajax only. It only ever needed to load one page (my reason for this is unimportant here). The interesting part comes in that I had a special need to return some data to be operated on in the javascript AND a partial view to be displayed. I could have split this up into two calls to two separate action methods but I decided to go with something a little more fun.

看看吧:

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节点:)

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

好吧,

我是极少数喜欢这样区分事物的人之一: -服务器负责传递数据(模型); -客户端负责显示(视图)和操作数据(模型);

因此，服务器应该专注于交付模型(在这种情况下JSON更好)。 通过这种方式，您可以获得灵活的方法。如果你想改变你的模型的视图，你让服务器发送相同的数据，只改变客户端，javascript组件，将数据改变为视图。想象一下，你有一个服务器向移动设备和桌面应用程序传递数据。

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

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

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

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

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